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(54) Title: COMMON CHARGING IDENTIFIER FOR COMMUNICATION NETWORKS 

(57) Abstract: In a first embodiment of the invention, when 1 an Activate PDP Context Request message is forwarded to a Service 
GPRS Support Node (SGSN), the SGSN creates a Create PDP Context Request message and forwards it to a Gateway GPRS Support 
Node (GGSN). In response to the Create PDP Context Request forwarded by the SGSN, the GGSN creates a Create PDP Context 
Response message. When a PDP context is created .by, the GGS>J, the GGSN associates a Globally Unique Charging Identification 
(GO) with the PDP context. Then, the Create PDP, ContexbRcsponsc,. including the GO is forwarded;to the SGSN. The GO is sent 
from the SGSN to the UE and from the UE to the CSCF. In a second embodiment of the invention, the GO is sent from the SGSN or 
the GGSN directly to the Call State Control Function (CSCF). Sending the GO can be performed either autonomously or based on 
a request from the CSCF. In either embodiment, the CSCF can send the GO to a second network which performs processing, such 
as billing, from data collected from call detail records associated with the GO. 
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COMMON CHARGING IDENTIFIER 
FOR COMMUNICATION NETWORKS 

I 4 * ■ • 

TECHNICAL FIELD 
The present invention relatiesjtp communication networks and, more 
particularly, the present invention relates 'to techniques for charging coordination and 
other kinds of information coordination, and a common charging identifier for 
communication networks. 

i 

* 

BACKGROUND ART 
In general, packet switched wireless networks provide communications for 
mobile terminals with no physical connection required for network access. The 
General Packet Radio Service (GPRS) in the Global System for Mobile 
Communications (GSM) and the Universal Mobile Terrestrial System (UMTS) have 
both been developed to provide wireless communications networks with a packet 

4 

switched side, as well as a circuit switched side. 

The specifications for UMTS networks with further improvements have been 
released by the 3rd Generation Partnership Program (www.3gpp.orgV Release 00 of 
the UMTS specifications proyijde^that, ^network subscriber can have one or more 
packet data protocol (PDP), addresses; Each PDP address is described by one or more 
PDP contexts in the Mobile Terminal (MT), the Service GPRS Support Node 
(SGSN), and the Gateway GPRS Support Node (GGSN). The GGSN is a gateway to 
external networks. Each PDP context may have routing and mapping information for 
directing the transfer of data to and from ;its associated PDP address and a traffic flow 
template (TFT) for filtering the transferred data. 

Each PDP context can beiselectively and independently activated, modified, 
and deactivated. The activation state of a PDP context indicates whether data transfer 
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is enabled for a corresponding PDP address and TFT. , If all PDP contexts associated 

s • ' • ' i 

with the same PDP address are inactive or deactivated, all data transfer for that PDP 
address is disabled. All PDP contexts of a subscriber are associated with the same 
Mobility Management (MM) context for the International Mobile Subscriber Identity 
5 (IMSI) of that subscriber. Setting up a PDP context means setting up a 
communication channel. 

FIG. 1 is a process flow diagram that illustrates an example of the PDP context 
activation procedure. In step 1 00, the MT sends an Activate PDP Context Request to 
the SGSN. The Activate PDP Context Request message sent in step 100 includes a 
1 0 number of parameters. The parameters include a PDP address and an Access Point 
Name (APN). The PDP address is used to indicate whether a static PDP or dynamic 

* 

PDP address is required. The APN is a logical name referring to the Gateway GPRS 
Support Node (GGSN) to be used. 

In step 1 02, the SGSN sends a Radio Access Bearer (RAB) setup message to 
1 5 the UMTS Terrestrial Radio Access Network (UTRAN) or the GERAN or other 

i . 

i , i 

corresponding radio access networks . In step 1 04^ the SGSN sends a Create PDP 
Context Request message to the affected GGSN. The GGSN decides whether to 
accept or reject the request. If it accepts the request, it modifies its PDP context table 
and returns a Create PDP Context Response message in step 106. The SGSN then 

20 sends an Activate PDP Context Accept message to the Mobile Terminal in step 1 08. 

In Release 00 of the Universal Mobile Telecommunications System 
specifications (UMTS), a new architecture with existing and new logical entities is 
introduced to support IP multimedia services including, e.g., IP telephony. SIP 
(Session Initiation Protocol) is used for call control. The caller allocates a Call Id, 

25 which is included in SIP messages. The Call Id,uniquely identifies the call and is used 

I * 

a 

by all call participants However, the use of the Call ID is complicated in the case of a 
mobile station (MS) comprised of mobile terminal (MT) and terminal equipment (TE) 
parts since the MT driver in the TE is preferably able to filter the UDP/IP packets 

■ • j it: *•• . !■ ' ' ; !■ . 
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forwarded to the MT, and be able to parse the majority if not the entire SIP grammar 
to find the Call-ID field contained somewhere in a UDP datagram. 

The subscribers of voice services are accustomed to receiving bills based on 
calls, not based on the transport resources: used .for making the calls. Subscribers of IP 
telephony often expect similar billing. criteria. Consequently, billing for the services 
used (e.g., for the calls) rather than the transport resources used is becoming 
increasingly important. In the case of Wireless Application Protocol (WAP) services, 
billing for services rather than transport resources is already the expectation. 

For an IP telephony call, a PDP context is required to carry the actual voice 
traffic. Both the GPRS/UMTS layer and the IP telephony layer collect charging 
information (CDRs): the GPRS/UMTS layer collects charging information for the 
PDP context while the IP telephony layer collects charging information for the call. A 
common identifier ought to be added to the CDRs to make it possible to bill based 
only on the CDRs created by the IP telephony layer (i.e., for services) and to omit the 
CDRs created by the GPRS/UMTS layer (i.e., for transport resources). 

A common identifier is needed; in the CDRs created by the GPRS/UMTS layer 
and by the IP telephony layer to make it possible to omit certain CDRs and enable 
billing based on services rather,! than use of .transport resources. More specifically, in 
many cases it would be advantageous to selectively, omit CDRs created by the 
GPRS/UMTS layer or CDRs created by the IP telephony layer. If that were possible, 
the billing would be operator-specific, in that the operator could decide how to bill the 
subscribers (how to use the created CDRs). :. 

In spite of the numerous details provided in the aforementioned protocol, 
many features associated with mobile networks have not been dealt with. 
Specifically, charging information can be created by the SGSN, the GGSN and by the 
IP telephony network elements, e. g. the CSCF. At present there is no solution in 
place to associate the charging information created by the SGSN, the GGSN and the 
charging information created by the CSCF. Indeed, the network may be so 
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complicated (e.g., the charging data may; be generated in many different network 
elements) that it is not possible to combine all call event related data. At least some 
of this data is needed in order to implement network functionality such as hot billing 
or merely to allow a network operator to implement joint billing for GPRS services 
5 and IP telephony services, ; 

i 

DISCLOSURE OF THE INVENTION 
According to a first illustrative embodiment of the invention, when an 
Activate PDP Context Request message is forwarded to a Service GPRS Support 
Node (SGSN) by an MT, the SGSN creates a Create PDP Context Request message 

10 and forwards it to a Gateway GPRS. Support Node (GGSN). In response to the Create 

PDP Context Request forwarded by the SGSN, the GGSN creates a Create PDP 
Context Response message. When a PDP context is created by the GGSN, the GGSN 
associates a Charging Identification parameter with the PDP context. Then, the Create 
PDP Context Response including the; Charging Identification parameter is forwarded 

1 5 to the SGSN. In response to the PDP Context Response forwarded by the GGSN to 

the SGSN, the SGSN forwards an Activate PDP Context Accept message to the MT. 
According to the first embodiment of the invention, both the Charging Identification 
parameter and possibly the GGSN address are provided to the MT in the Activate 
PDP Context Accept message. As described herein, the mobile station (MS) includes 

20 two parts: the terminal equipment (TE) and the mobile terminal (MT). The MS may 

also be referred to as user equipment (UE). The TE can, e.g., be a laptop which is 
then connected to the MT. The MT can be a mobile phone. 

M ■ • 

Sending the GGSN address isjiot mandatory. Another alternative is that the 
CSCF adds the IP address of the MS to ; the charging records (CDRs) that it creates for 
25 a call. The SGSN and the GGSN already add the PDP address of the PDP context to 

the CDRs. By checking that the PDP address is the same as the IP address, it can be 
ensured that the PDP context has been used for the call in question. Since this 

• * * * * . . i 
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requires that the charging identifications are the same, the CSCF adds the Charging 
Identification to the CDRs that it creates for the call in question. 

According to a second illustrative'embodiment of the invention, the Charging 
Identification can be sent from the SGSN or the GGSN to the Call State Control 
Function (CSCF). When an Activate PDP Context Request message is forwarded to 
the SGSN, the SGSN creates a Create PDP Context Request message. The SGSN 
sends the Create PDP Context Request to the GGSN. In response to the Create PDP 
Context Request received from the SGSN, the GGSN creates a Create PDP Context 
Response. The GGSN associates the Charging Identification parameter with the PDP 
context. The Create PDP Context Response including the Charging Identification 
parameter is then forwarded to the SGSN. 

The Charging Identification parameter can be sent from either of the SGSN or 
the GGSN directly to the CSCF; and, such sending of the Charging Identification 
parameter can be performed either autonomously, e.g., at PDP context activation, or 
based on a request from the CSCF. 

In a specific embodiment/the CSCF sends the charging identification towards 
an endpoint of a communication,! aridi sends security information together with said 
charging identification toward, the endpoint. The CSCF is able to send an address of a 
GGSN together with the charging identification to the endpoint. If the GGSN address 
is not sent with the charging identification, the CSCF adds the IP address of the 
mobile station (UE) to the CDRs. ; <<' • - 

In a variation of the first and second illustrative embodiments, the Charging 
Identification parameter is a Globally Unique Charging Identification (GCI). 
(Although referred to in this application as "globally" unique, the charging 
identification need only be utilized by as few as only two networks.) The GCI is used 
during a call to ease combination of call event related data from different network 
elements. One particular feature of theembodiment is that the GCI can be generated 
by any network element. It can be generated by the SGSN, GGSN or CSCF. Such a 
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network element can be a 2 nd generation network element or a 3 generation network 
element. In any event, the network elements (other than the network element which 
generated the GC1) do not need to generate a charging identification, but instead use 

* * 

the GCI generated by the other network element. The GO can be used to ease 
5 combination of all call event related data or any portion thereof. As an example, the 
GCI and all the charging data for a call event can be collected and used by another 
network, such as one including a post-processing system providing billing for network 
subscribers. 

The principles of the invention are applicable to other types of communication 
1 0 channels in addition to PDP contexts. 

• * 

For an IP telephony call, a PDP context is required to carry the actual voice 

» 

traffic. Both the GPRS/UMTS layer and the IP telephony layer collect charging 
information (CDRs): The GPRS/UMTS layer collects charging information for the 
PDP context while the IP telephony layer collects charging information for the call. 

1 5 According to a third illustrative embodiment of the invention, a common identifier is 

added to the CDRs, which, for example, makes it possible to bill based on the CDRs 
created by the IP telephony layer (i.e., for services) and omit the CDRs created by the 
GPRS/UMTS layer (i.e., for transport resources). 

According to the principles of the third embodiment of the invention, the 

20 common identifier is associated with the CDRs created by the GPRS/UMTS layer and 

by the IP telephony layer. The common identifier enables charging coordination and 
other kinds of information coordination. 

A call in SIP is identified by the Call Identification which is used as the 

i 

i 

common identifier. The Call Identification is allocated by the caller and included in 
25 the SIP messages. The MS sends the SIP messages to the called party via the CSCF. 

The CSCF intercepts the SIP messages and can thereby obtain the Call Identification 
from the SIP messages. ■ ■ , '" i • ' ' \ « ' 

i i ■ . i 
• . ; • . 
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To use the Call Identification. for charging coordination or other kinds of 
information coordination in accordance with the principles of the invention, the MS 
sends the Call Identification to the SGSN and the GGSN during PDP context 
activation. More specifically, the MS sends the Call Identification to the SGSN along 
with the Activate (Secondary) PDP Context Request message, and the SGSN forwards 
the Call Identification to the GGSN along with the Create PDP Context Request 
message. 

The process described herein works for both mobile-originated calls (where 
the MS allocates the Call Identification) and mobile-terminated calls (where the MS 
receives the Call Identification in the SIP Invite message). According to the process 
described herein, the SGSN and the GGSN add the Call Identification to the CDRs 
that they create for the PDP context, and the CSCF adds the Call Identification to the 
CDRs that it creates for the call. 

A fourth embodiment of the invention is similar to the third embodiment, 
except that a unique identifier is formed by using the UDP port number present in the 
SDP syntax of SIP ^INVITE" and 4 M l 83 Session Progress" messages instead of the 
Call-ID field. 

In either of these embodiments, an operator is given greater flexibility in 
deciding how to bill subscribers for the created) CDRs. The operator can selectively 
omit billing for CDRs created by ithe GPRS/UMTS layer while choosing to bill for 
CDRs created by the IP telephony layer. 

Other aspects and advantages of the invention will become apparent from the 
following detailed description and accompanying drawings, illustrating by way of 

example the features of the invention. 

■ ; 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing and a better understanding of the present invention will become 
apparent from the following! detailed description of example embodiments and the 
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claims when read in connection with the accompanying drawings, all forming a part of 
the disclosure of this invention. While the foregoing and following written and 
illustrated disclosure focuses on disclosing example, embodiments of the invention, it 
should be clearly understood that the same is by way of illustration and example only 
and the invention is not limited thereto. The spirit and scope of the present invention 

■ 

are limited only by the terms of the appended claims. 

FIG. 1 is a generalized process floW diagram illustrating the PDP context 
activation procedure. 

FIG. 2 is a generalized block diagram of the architecture of a packet switched 
wireless communication network in which the example embodiments of the invention 
can be practiced. 

FIG. 3 is a generalized process flow diagram illustrating sending a charging 
identification in accordance with a first embodiment of the present invention. 

FIG. 4 is a generalized process floW diagram illustrating sending a charging 
identification in accordance with an arrangement of a second embodiment of the 

present invention. ■ ; 

FIG. 5 is a generalized process flow diagram illustrating sending a charging 
identification in accordance with another arrangement of the second embodiment of 
the invention. < 

FIG. 6 is a generalized process, flow diagram illustrating sending a call 
identification in accordance with a third embodiment of the invention. 

FIG. 7 is a generalized signaling flow diagram illustrating coordination of the 
application layer and transport layer in accordance with an arrangement of the third 
embodiment of the invention. . !"' 

FIG. 8 is a generalized signaling flow diagram illustrating coordination of the 
application layer and transport layer in accordance with another arrangement of the 
third embodiment of the invention. 

FIG. 9 is a generalized process flow diagram illustrating sending a tuple or 

■ 

8 : .. 
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tuple pair in accordance with a fourth embodiment of the invention. 

FIG. 10 is a generalized signaling flow diagram illustrating coordination of the 

i 

application layer and transport, layer in accordance with an arrangement of the third 
embodiment of the invention. 
5 FIG. 1 1 is a generalized signaling flow diagram illustrating coordination of the 

application layer and transport layer in accordance with another arrangement of the 
fourth embodiment of the invention. 

BEST MODE FOR CARRYING OUT TH E INVENTION 
Before beginning a detailed description of the subject invention, mention of 
1 0 the following is in order, when appropriate, like reference numerals and characters 

may be used to designate identical, corresponding, or similar components in differing 
drawing figures. Furthermore,; in the detailed description to follow, example 
sizes/models/values/ranges may be given, although the present invention is not limited 

thereto. .. 

■ 

15 An example of a network architecture supporting these specifications is the 

wireless communications network shown in the block diagram of FIG. 2. The various 

elements of the network and their functions are, described in the General Packet Radio 

• . * ■ ■ - 

Service (GPRS) Service Description, Stage 2,,3GPP TS 23.060, published by the 3rd 
Generation Partnership Program ( www.3epp.org) . The elements and their functions 

20 may be described in earlier or later versions of the 3GPP TS 23.060 specifications or 
may be those of any other known packet switched wireless communications network. 
The description of network elements and their functions are merely a non-limiting 
example of packet switched wireless communication networks. 

Several elements of the example network illustrated in FIG. 2 are particularly 

25 relevant to this invention. The Mobile Terminal (MT), commonly referred to as a cell 

i 

phone or a mobile phone, is only one possible part of User Equipment (UE). 
Typically, Terminal Equipment (TE), used together with a Mobile Terminal (MT), 

9 
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constitutes User Equipment (UE), which is also referred to as a Mobile Station (MS). 

i e 

Any UE may be utilized in conjunction with this invention so that it operates or can be 
programmed to operate in the manner described below. The UMTS Terrestrial Radio 
Access Network (UTRAN) and the Base Station System (BSS) in GPRS manage and 
control the radio access between the core network and a number of MTs. There are 
also other possible radio access networks like GERAN. 

The CSCF is a network element in an IP telephony network. The IP telephony 
network is sometimes referred to as "the application layer". The structure and 
function of the Call State Control Function (CSCF) can be divided into several logical 
components, which are currently internal to the CSCF. Every CSCF acting as a 
Serving CSCF has a Call Control Function (CCF) function. The CSCF includes an 
ICGW (Incoming call gateway). The ICGW acts as a first entry point. The ICGW 
performs routing of incoming calls. Incoming call service triggering (e.g. call 
screening /call forwarding unconditional) may need to reside for optimization 
purposes. The ICGW performs Query Address Handling (implies administrative 
dependency with other entities); and communicates with the Home Subscriber Server 
(HSS). 

The CCF (Call Control Function) performs call set-up/termination and 
state/event management; interacts with MRF in order to support multi-party and other 
services; reports call events fonbilling* auditing, intercept or other purposes; receives 
and process application layer registration; performs query address handling (implies 
administrative dependency); and may provide service trigger mechanisms (service 
capabilities features) towards application & services network (VHE/OSA). The CCF 
may invoke location based services relevant to the serving network, and may check 
whether the requested outgoing communication is allowed given the current 
subscription. 

The CSCF includes a SPD (Serving Profile Database). The SPD interacts with 
HSS in the home domain to receive profile information for the R00 all-IP network 
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user and may store them depending on the SLA with the home domain. The SPD 
notifies the home domain of initial user's access (which includes, e.g., CSCF 
signaling transport address, user ID, etc.) The SPD may cache access related 
information (e.g. terminal IP address(es) where the user may be reached, etc.) 
5 The CSCF performs AH (Address Handling) function. The AH function 

includes analysis, translation, modification, if required, address portability, and 
mapping of alias addresses. The AH function may do temporary address handling for 
inter-network routing. 

The Serving GPRS Support Node (SGSN) is the node that serves the MT. At 

10 PDP context activation, the SGSN establishes a PDP context used for routing 

purposes. The Gateway GPRS Suppqft Node (GGSN) is the node accessed by the 
external packet data network due Jo evaluation of the PDP address. It contains routing 
information for attached GPRS/UMTS users. The routing information is used to 
tunnel Protocol Data Units (PDUs) to the SGSN. The SGSN and GGSN 

] 5 functionalities may reside in different physical nodes or may be combined in the same 

physical node, for example, the Internet GPRS Support Node (IGSN). 

The IP-based mobile network architecture includes an application layer and a 
transport layer. The transport layer protocols and mechanisms are usually optimized 

for the specific type of access whereas the application layer is normally generic, that is 

i 

20 independent of the type of access. 

In IP-based mobile networks, the UE sets up a call by signaling to the peer 
entity and exchanging messages of a call control protocol over an IP connection 
provided by the transport layer. In setting up a call in the application layer, the 
underlying transport layer has to set up the transport bearers over the radio interface 

25 and in the transport network. For an AP-based mobile network, setting up of transport 

bearers means allocating radio resources and network resources. The call control 
signaling is transparently exchanged over an IP connection provided by the transport 

» 

layer. « ■." : ; 

» 1 
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Embodiment 1 

FIG. 3 illustrates a process of sending a charging identification in accordance 
with a first embodiment of the present invention. In UMTS all-IP networks, when 
GPRS/UMTS is adopted as access/transport network for multimedia and voice over IP 
5 services, charging will be performed independently at the GPRS/UMTS layer and at 

the application layer (e.g., the CSCF). 

In the GPRS and UMTS networks, PDP contexts are created by the GGSN 
upon request from the SGSN (with a Create PDP Context Request message) that, in 
turn, receives the request from the MT (an Activate PDP Context Request message). 

10 As illustrated in FIG. 3, the technique in accordance with the present invention 

begins at the application layer at step 300 in whifch a trigger is forwarded from the TE 
(Terminal Equipment) to the MT (Mobile Terminal). The trigger may be, e.g., a call 
set up indication including the requested logical channels and characteristics, sent 
from the TE to the MT to start PDP context activation. 

1 5 At step 302, an Activate PDP Context Request message is forwarded to the 

SGSN. In response thereto, in step 304, the SGSN creates a Create PDP Context 
Request message and forwards /it to the GGSN. In response to the Create PDP 
Context Request forwarded by'the S<§SK in step 306, the GGSN creates a Create 
PDP Context Response message. 

20 In step 308, when a PDP context is created by the GGSN, the GGSN 

associates a Charging Identification parameter with the PDP context in step 308. 
Then, in step 3 1 0, the Create PDP Context Response message including the Charging 
Identification parameter is forwarded to the SGSN. 

In turn, in response to the PDP Context Response forwarded by the GGSN to 

25 the SGSN, in step 3 1 2, the SGSN forwards an Activate PDP Context Accept message 

to the MT. According to the first embodiment of the invention, both the Charging 
Identification parameter and the GGSN Address are provided to the MT in the 
Activate PDP Context Accept message. , 

» ■ 

12 
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The above noted procedures in steps 300-3 12 are repeated as many times as 

needed depending on the PDP contexts needed. 

i ... 

Upon the completion of the last procedure in step 3 1 2, the UE forwards a call 
set up message, including requested logical channels and characteristics, to the CSCF 
5 (Call State Control Function) in step 3 1 4. The MT will, in turn, provide the Charging 

Identification and the GGSN Address to the CSCF within the call set up message. 

i . 

The CSCF, in turn, forwards the call set up message, including requested logical 
channels and characteristics, to the remote end point in step 3 1 6. The remote end 
point then forwards a response message, including accepted logical channels and 
1 0 characteristics, back to the CSCF in step 3 1 8. The CSCF then forwards the response 

i i ' 

message, including accepted logical channels and characteristics, to the UE in step 
320. The response message may be, e.g., the Connect message in H.323 or a SIP 
response message, but not necessarily limited to those. 

The invention contemplates that the Charging Identification parameter can be 

■ ' * i ii 

1 5 made more secure by applying appropriate cryptographic algorithms to avoid a false 

t ■ i 

Charging Identification being forwarded by a malicious MT to the CSCF instead of 
the legitimate value, or a malicious MT re-using a value of the Charging 
Identification. 

From the foregoing, it will be appreciated that in the first embodiment of the 
20 invention, the Charging Identification parameter is sent from the SGSN to the UE and 
from the UE to the CSCF. . 

Embodiment 2 

FIG. 4 illustrates a process of sending a charging identification in accordance 
with an arrangement of a second embodiment of the present invention. In UMTS all- 
25 IP networks, when GPRS/UMTS is adopted as the access/transport network for 

multimedia and voice over IP services, charging will be performed independently at 
the GPRS/UMTS layer and at the application layer (e.g., the CSCF). 

' , • i ■ I 
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In the GPRS and UMTS networks, PDP contexts are created by the GGSN 
upon request from the SGSN (i.e., a Create PDP Context Request message) that, in 
turn, receives the request from the MT (i.e., an Activate PDP Context Request). 

: : : \ * 

According to the second embodiment of the invention, the Charging Identification 
5 parameter is sent from the SGSN or the GGSN to the CSCF. Unlike the first 

embodiment, there is no need to send the Charging Identification parameter via the 
UE. 

As described previously, in the first embodiment of the invention, the MT 
intercepts data packets that are sent from the TE and adds the Charging Identification 
1 0 parameter to a specific data packet ( the SIP message or the H.323 message for call set 
up). Interception of data packets may decrease the performance of the MT. 

In the second embodiment of the invention, the GPRS/UMTS and IPT 
network elements are able to coordinate charging information or other kinds of 
information, e.g., in order to combine charging information collected for a PDP 
1 5 context by the SGSN and the GGSN and for a call by the CSCF. Like the first 

r 

embodiment, the GGSN allocates: a: Charging Id parameter at PDP context activation. 

' ■* >;? 1 ! ' 

And like the first embodiment, the GGSN sends the Charging Id parameter to the 
SGSN. But, unique to the second embodiment, the Charging Identification, possibly 
together with other information (e.g., IMSI, MSISDN, PDP address, UE port number 

I F 

20 from the TFT, Charging Characteristics etc.) can be sent from the SGSN or the GGSN 

to the CSCF. 

Sending the Charging Id parameter can be performed either autonomously or 
based on a request from the CSCF. The SGSN will send the Charging Identification, 
since the address of the CSCF has to be known if something will be sent to it. The 
25 SGSN has an interface with the HSS (HLR+UMS), which contains the address of the 

serving CSCF. 

There also can be an interface between the GGSN and the CSCF. This new 
interface could then be used to carry the Charging Id and possibly other charging 

! 

t . • < 
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related information. FIG. 4 illustrates an aspect of the second embodiment of the 
invention in which the SGSN sends the Charging-ld parameter to the CSCF. 

As illustrated in FIG. 4, a process of sending a charging identification in 
accordance with the present invention begins at step 400 in which a trigger is 
5 forwarded from the TE (Terminal Equipment) to the MT (Mobile Terminal). The 

trigger may be, e.g., a call set up message including the requested logical channels and 
characteristics. 

At step 402, an Activate PDP Context Request message is forwarded to the 

X ■ * » 

. 1 ft , * 

SGSN. In response thereto, in step 404, the SGSN creates a Create PDP Context 
10 Request message. 

In step 406, the SGSN sends the Create PDP Context Request to the GGSN. 
In response to the Create PDP Context Request received from the SGSN, in step 408, 

► 

the GGSN creates a Create PDP Context Response. In step 410, the GGSN associates 
the Charging Identification parameter with the PDP context. In step 412, both the 

' , • j 1 

1 5 Create PDP Context Response and the Charging Identification are then returned to the 

SGSN in the Create PDP Context Response: message. 

The Charging Id is included in the CDRs created by the GGSN and the SGSN. 
The CDRs are sent to the Charging Gateway Functionality (CGR) for further 
processing. From the Charging Gateway Functionality, the CDRs are sent to the 

20 Billing System. This is true for all the embodiments. In addition, it is important that 

the CSCF adds the Charging Id to the CDRs that it creates for the call in question. 
The CSCF sends CDRs either to the Charging Gateway Functionality (CGF) or to the 
Billing System. This way, when creating a bill for a subscriber, the PDP context(s) 

■ K » 

that were used for a specific call can be checked. The Charging Identification in all 
25 those CDRs is the same. 

If the Charging Characteristics change: during an active PDP context, the 
SGSN includes the new Charging Characteristics of the PDP context in an Update 
PDP Context Request message, which the SGSN sends to the GGSN. 

I t ■ 
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According to this arrangement of the second embodiment, the Charging Id 
parameter, possibly together with other information (e.g., IMSI, MSISDN, PDP 
address, UE port number from the TFT, Charging Characteristics etc.), is sent from 
the SGSN directly to the CSCF in step 414. This is done either autonomously (in a 
5 first case) or based on a request from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the SGSN sends 
a message including the Charging Id and possibly other information (see above) to the 
CSCF. The message sent by the SGSN may be acknowledged by the CSCF. 

The SGSN must know the CSCF address. The CSCF address may be 
1 0 requested from the HSS or may be derived from the TFT which the UE specifies for 
the PDP context which is used for the communication with the CSCF. 

In the second case, at call set up, the CSCF requests information from the 
SGSN. The request is based, e.g., on IMSI or MSISDN. The SGSN sends the 

i ■ • i I 

Charging Id and possibly other information (see above) to the CSCF. 

1 5 The CSCF must know the SC3SN address. The SGSN address may be 

requested from the HSS. 

The CSCF, in turn, forwards the call set up message to the remote end point in 
step 416. The remote end point then forwards a response message back to the CSCF 
in step 418. The CSCF then forwards the response; message to the UE in step 420. 

20 FIG. 5 illustrates another arrangement of the second embodiment of the 

invention in which the GGSN sends the Charging Identification directly to the CSCF. 
Referring to FIG. 5, a process of sending a charging identification in accordance with 
the present invention begins at step 500 in which a trigger is forwarded from the TE to 
the MT (Mobile Terminal).: The trigger may be, e.g., a call set up message including 

25 the requested logical channels and characteristics. 

At step 502, an Activate PDP Context Request message is forwarded to the 
SGSN. In response thereto, in step 504, the SGSN creates a Create PDP Context 

* 

Request message. In step 506 it the SGSNpends the Create PDP Context Request to 

: i • 1 : • ' « 
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the GGSN. . • 

In response to the Create PDP Context Request received from the SGSN, in 
step 508, the GGSN creates a Create PDP Context Response. In step 510, the GGSN 
associates the Charging Identification parameter with the PDP context. In step 512, 
the Create PDP Context Response message including the Charging Identification is 
then returned to the SGSN. 

. * ' ■, . _. 

According to this aspect of th;^ second embodiment, the Charging Id 
parameter, possibly together with other information (e.g., IMSI, MSISDN, PDP 
address, UE port number from the TFT, Charging Characteristics etc.), is sent from 
the GGSN directly to the CSCF in step 5 1 4. Step 5 1 4 is performed either 
autonomously (in a first case) or based on a request from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the GGSN 
sends a message including the Charging Id and possibly other information (see above) 
to the CSCF. The message sent by the GGSN may be acknowledged by the CSCF. 

The GGSN needs to know the CSCF address. The CSCF address may be 
requested from the HSS or may be derived from the TFT which the UE specifies for 
the PDP context that is used for the communication with the CSCF. 

In the second case, at call set up, the CSCF requests information from the 
GGSN. The request is based, e.g., on IMSI or MSISDN. The GGSN sends the 
Charging Id parameter and, possibly other information to the CSCF. 

The CSCF forwards the call s?t up message to the remote end point in step 
5 1 6. The remote end point then forwards a responsb message back to the CSCF in 
step 518. The CSCF then forwards the response message to the UE in step 520. 

The second embodiment allows the GPRS and IPT network elements to 
coordinate charging information and other kinds of information, e.g., in order to 
combine charging information collected for a, PDP context by the SGSN and the 
GGSN and for a call by the CSCF. Sending the Charging Identification from the 

i 

i 
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SGSN or the GGSN to the CSCF requires an interface between the application layer 

♦ ■ « 

network and the transport layer network. . 

r I ' 

Variation of Embodiments 1 and 2 

i . i , 

In a variation of the first and second embodiments, the Charging Identification 
generated in the SGSN, GGSN or other network element is a Globally Unique 
Charging Identification (GCI). The GCI is a combination of the integer value 2a32-1 
(4 bytes) and the ID of the network element which generated it (such as the SGSN or 
GGSN). The length or structure of the network element ID generating the GCI may 
vary according to the specific implementation. It is not necessary that the GCI be 
generated in any particular group of network elements. In any circumstance, the 
remaining network elements simply receive and use the GCI generated by the first 

■ v* 

network element. , . 

After the GCI is generated, it is used during the entire call and the other 
network elements don't generate a charging identification, but instead use the GCI 

generated by the first network element. The GCI is created and transferred over 

■ . * ' * - 

several interfaces in the place of the Charging Identification described above. A 
plurality of separate call detail records (CDRs) can be generated and associated with 
each other using the GCI. For example, the SGSN may create a S-CDR and the 
GGSN may create a G-CDR as explained in 3G TS 32.01 5. The CSCF (together with 
a MGCF) may create a C-CDR. A terminating network (such as a PSTN/MSC) may 
create POC and MTC CDRs. 

When an endpoint (such as a MGCF) receives the GCI passed from the CSCF, 
it may pass it on to another network. Preferably, the GCI can be transferred to, within 
and between 2 nd generation ("2G") networks as well as the 3G network described 
above. The SIP and GTP' protocblSimay;be used to carry the GCI in the 3G network 
as described above, and the corresponding protocols in a 2G network may be modified 
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so that they can also carry the GC1. As an example, the connected 2G network may be 
a post-processing system which produces subscriber billing by effectively using the 
GCI to determine and combine charging data for the subscriber in one or more CDRs. 

j 

j • 

A . Embodiment 3 

5 The subscribers of voice services are accustomed to receiving bills based on 

. i. 

calls, not based on the transport resources used for making the calls. Subscribers of IP 
telephony often expect similar billing criteria. Consequently, billing for the services 
used (e.g., for the calls) rather than the transport resources used is becoming 
increasingly important. In the case of WAP services, billing for services rather than 

1 0 transport resources is already the expectation. 

For an IP telephony call, a PDP context is required to carry the actual voice 
traffic. Both the GPRS/UMTS layer and the IP telephony layer collect charging 
information (CDRs): The GPRS/UMTS layer collects charging information for the 
PDP context while the IP telephony layer collects charging information for the call. A 

1 5 common identifier ought to be added to the CDRs to make it possible, for example, to 

bill based only on the CDRs created by the IP telephony layer (i.e., for services) and to 
omit the CDRs created by the GPRS/UMTS layer (i.e., for transport resources). 

A common identifier is needed in the CDRs created by the GPRS/UMTS layer 

• ■ ■ * " . 

and by the IP telephony layer to make it possible to omit certain CDRs and enable 
20 billing based on services rather than use of transport resources. More specifically, in 

many cases it would be advantageous to selectively omit CDRs created by the 
GPRS/UMTS layer or CDRs created by the IP telephony layer.. If that were possible, 
the billing would be operator-specific, in that the operator could decide how to bill the 
subscribers (how to use the created CDRs). 
25 According to the principles of the invention, a common identifier is associated 

with the CDRs created by the GPRS/UMTS layer and by the IP telephony layer. The 
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common identifier enables charging coordination and other kinds of information 
coordination. 

Instead of using a GGSN-allocated Charging Identification, a call in SIP is 
identified with a Call Identification, which is used as a charging coordinator. The Call 
Identification is allocated by the caller and included in the SIP messages. The MS 
sends the SIP messages to the called party via the CSCF. The CSCF intercepts the 
SIP messages and can thereby obtain the Call Identification from the SIP messages. 

To use the Call Identification for charging coordination or other kinds of 
coordination in accordance with the principles of the invention, the MS sends the Call 
Identification to the SGSN and the GGSN during PDP context activation. More 
specifically, the MS sends the Call Identification to the SGSN along with the Activate 
(Secondary) PDP Context Request message, and the SGSN forwards the Call 
identification to the GGSN along with the Create PDP Context Request message. 

FIG. 6 illustrates a process for coordinating charging in accordance with a 
third embodiment of the invention, which advantageously enhances coordination of 
information between transport and application layers. As illustrated in FIG. 6, the 
technique in accordance with the present invention begins at the application layer at 
step 600 in which a trigger is forwarded from the TE (Terminal Equipment) to the MT 

* 

(Mobile Terminal). The trigger may be, e.g., a call set up indication including the 
requested logical channels and characteristics, sent from the TE to the MT to start 
PDP context activation. In step 602, the MS initiates a transaction in the form of a 
call. In step 604, the MS assigns a call identification to the call. The process 
described herein works for mobile-originated calls (where the MS allocates the Call 
Identification), as described subsequently with respect to FIG. 7, and also for mobile- 
terminated calls (where the MS receives the Call Identification in the SIP Invite 
message), as described subsequently with respect to FIG. 8. In step 606, the call 
identification is sent from the MS to the CSCF. 
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In step 608, an Activate (Secondary) PDP Context Request message and a Call 
Identification is forwarded from the MS to the SGSN. In step 610, the SGSN sends a 
Radio Access Bearer (RAB) setup message to the UTRAN. In response thereto, in 
step 612, the SGSN creates a Create PDP Context Request message and forwards it to 
the GGSN along with the Call Identification. In response to the Create PDP Context 
Request forwarded by the SGSN, in step 614, the GGSN creates a Create PDP 
Context Response message. . 

In step 616, the Create PDP Context Response message is forwarded to the 
SGSN. In response to the PDP Context Response forwarded by the GGSN to the 
SGSN, in step 618, the SGSN forwards an Activate (Secondary) PDP Context Accept 
message to the MS. 

According to the process described herein, the SGSN and the GGSN add the 
Call Identification to the CDRs that they create for the PDP context, and the CSCF 
adds the Call Identification to the CDRs that it creates for the call. 

Accordingly, an operator is given greater flexibility in deciding how to bill 
subscribers for the created CDRs. The operator can selectively omit billing for CDRs 
created by the GPRS/UMTS layer while choosing to bill for CDRs created by the IP 
telephony layer. 

FIG. 7 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with an arrangement of the third embodiment 
of the invention. To enable charging coordination or other kinds of information 
coordination for a mobile-originated call, the Call Id is sent to the CSCF at call set up 
and to the SGSN and to the GGSN at PDP context activation. With reference to FIG. 
7, at 700, the MS allocates a Call Id and sends it to the CSCF in the SIP Invite 
message. At 702, the MS activates at least one PDP context for the call. The MS 
sends the Call Id to the SGSN in the Activate (Secondary) PDP Context Request 
message. If multiple PDP contexts are activated for the call, the MS has to send the 
Call Id to the SGSN at every PDP context activation. At 704, the radio access bearer 

i 
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setup is performed. At 706, the SGSN sends the Call Id to the GGSN in the Create 
PDP Context Request message. At 708 and 710, the (secondary) PDP context 

■ 

activation is accepted. ' " ' 

FIG. 8 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with another arrangement of the third 
embodiment of the invention. FIG. 8 presents an example of charging coordination 
for a mobile-terminated call. With reference to FIG. 8, at 800 the MS receives the SIP 
Invite message. The caller has allocated the Call Id for the call. At 802, the MS 
activates at least one PDP context for the call. The MS sends the Call Id to the SGSN 
in the Activate (Secondary) PDP Context Request message. If multiple PDP contexts 
are activated for the call, the MS has to send the Call Id to the SGSN at every PDP 
context activation. At 804, the radio access bearer setup is performed. At 806, the 
SGSN sends the Call Id to the GGSN in the Create PDP Context Request message. 
At 808 and 810, the (secondary) PDP context activation is accepted. 

Embodiment 4 

In another embodiment similar to Embodiment 3 described above, the 
common identifier associated with the CDRs created by the GPRS/UMTS layer and 
by the IP telephony layer is a tuple or tuple pair used to differentiate connections in IP 
networking. A "tuple" consists of theilP address and UDP port values related to the 
RTP data flow of the connection. A "tuple pair" consists of the tuples for both the 
source and destination side connection endpoints. To use the tuple or tuple pair for 
charging coordination or other kinds. of information coordination in accordance with 
the principles of the invention,: the MS sends them.to the SGSN and the GGSN during 
PDP context activation. More specifically, the MS sends them to the SGSN along 
with the Activate (Secondary) PDP Context Request message, and the SGSN forwards 
them to the GGSN along with the Create PDP Context Request message. 

■ * * 
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The process for coordinating charging in accordance with this fourth 
embodiment of the invention is illustrated in FIG. 9. At step 900, a trigger is 
forwarded from the TE (Terminal Equipment) to the MT (Mobile Terminal). The 
trigger may be, e.g., a call set up indication including the requested logical channels 
5 and characteristics, sent from the TE to the MT to start PDP context activation. In 

step 902, the MS initiates a transaction in the form of a call. In step 904, the MS 
assigns the tuple for each proposed media flow it suggests to use within the call. This 
information will then be carried in the SDP part of SIP INVITE and be used as 
destination tuple by the remote endpoint, if the remote endpoint agrees to use the 

1 0 proposed media. The process described herein works for mobile-originated calls 

(where the MS allocates the UDP/IP tuple values), as described subsequently with 
respect to FIG. 9, and also for mobile-terminated calls (where the MS receives the 
tuple in the SIP INVITE message), as described subsequently with respect to FIG. 9. 
In step 906, the tuple is sent from the MS to the CSCF. 

1 5 In step 908, the media negotiation? has traversed the necessary round-trips 

* * ■ ■ 

through the CSCF signalling chain and the terminating MS knows at least the initially 
agreed destination and source connection tuples (a tuple pair) for each media flow. 
Preferably, the P-CSCF of both the originating and terminating terminals parse and 
grab the tuple pair values frompassing SIP messages (for media authorization and 

20 policy control purposes). An Activate (Secondary) PDP Context Request message 

and the connection specific tuple pair information is forwarded from the MS to the 
SGSN. In step 910, the SGSN sends a Radio Access Bearer (RAB) setup message to 
the UTRAN. In response thereto, in step 912, the SGSN creates a Create PDP 
Context Request message and forwards it to the GGSN along with the tuple pair. In 

25 response to the Create PDP Context Request forwarded by the SGSN, in step 914, the 

GGSN creates a Create PDP Context Response message. 

In step 916, the Create PDP Context Response message is forwarded to the 
SGSN. In response to the PDP ; Context Response forwarded by the GGSN to the 

■ j "jf ■ \ f, • 
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SGSN, in step 918, the SGSN forwards an Activate (Secondary) PDP Context Accept 
message to the MS. 

According to the process described herein, the SGSN and the GGSN add the 
tuple pair to the CDRs that they create for the PDP context, and the CSCF adds the 
tuple pair present in media specific part (e.g., SDP) of SIP signalling to the CDRs that 

it creates for the call. 

Accordingly, an operator is given greater flexibility in deciding how to bill 
subscribers for the created CDRs The operator can selectively omit billing for CDRs 
created by the GPRS/UMTS layer while choosing to bill for CDRs created by the IP 
telephony layer. 

FIG. 10 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with an arrangement of the fourth embodiment 
of the invention. To enable charging coordination or other kinds of information 
coordination for a mobile-originated call, the tuple or tuple pair is sent to the CSCF at 
call set up and to the SGSN and to the GGSN at PDP context activation. With 
reference to FIG. 10, at 1000, the MS allocates a tuple for each proposed media flow it 
suggests to use within the call. This information will then be carried in a media 
specific (e.g., SDP) part of SIP INVITE and be used as destination tuple by the remote 
endpoint, if it agrees to use the proposed media. MS sends the tuples for each 
proposed media flow to the CSCF in the SIP INVITE message. Prior to this 
signalling, the MS activates at least one (signalling) PDP context for the call if one is 
not already activated. After the -media negotiation has traversed the necessary round- 
trips through the CSCF signalling ch&n and both originating and terminating terminal 
know the at least initially agreed destination and source connection tuples (a tuple 
pair) for each media flow, the MS sends the connection specific tuple pair to the 
SGSN in the Activate (Secondary) PDP Context Request message. If multiple PDP 
contexts (multiple media) are activated for the call, the MS has to send the tuple pair 
assigned to the particular media flow to the SGSN at every PDP context activation. 



1 



WO 01/91446 



PCT/IB01/00890 



At 1004, the radio access bearer setup is performed. At 1 006, the SGSN sends the 
tuple pair to the GGSN in the Create PDP Context Request message. At 1008 and 
1010, the (secondary) PDP context activation is accepted. 

» * 

FIG. 1 1 is a signaling flow diagram illustrating coordination of the application 
5 layer and transport layer in accordance with another arrangement of the fourth 

embodiment of the invention. FIG. 1 1 presents an example of charging coordination 

i 

or other kinds of information coordination for a mobile-terminated call. With 
reference to FIG. 1 1, at 1 100 the MS receives the SIP INVITE message. The caller 
has allocated the destination 'tuple values for each intended original or dynamically 

1 0 added media component for the call. At 1 1 02, the MS activates at least one secondary 

PDP context for the call. The MS sends the tuple or tuple pair to the SGSN in the 
Activate (Secondary) PDP Context Request message. If multiple PDP contexts are 
activated for the call, the MS has to send* the tuple or tuple pair to the SGSN at every 
PDP context activation. At 1 1 04, the radio access bearer setup is performed. At 

15 1 1 06, the SGSN sends the tuple pair to the GGSN in the Create PDP Context Request 

message. At 1 108 and 1110, the (secondary) PDP; context activation is accepted. 

The use of the tuple pairs in the fourth embodiment simplifies the terminal 
inter-layer (application layer - GPRS/UMTS layer) processing and can be used 
effectively regardless of whether the MS is a TE + MT combination or a unified UE. 

* 

20 This is because the connection specific UDP and TCP port information is sent 

■ 

automatically without need for specific MT interception/parsing process of SIP 
messages from TE (as in the third embodiment) or adding an extra message (charging 
ID received from SGSN) to TE-originated SIP messages. The port information is sent 
to both CSCF in SDP part of SIP INVITE or ACK message at application layer and to 
25 SGSN & GGSN in the TFT information of PDP Context Activation Request message 

(The tuple pair included to each PDP context's TFT needs to be forwarded to the 
MT's GPRS session management .layer - this can e.g. be done via MTs 

■ * 
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implementation specific bearer management or QoS application programming 
interface (API)). 

As a variation of the fourth embodiment, in the CSCF-GGSN interface end, 
the tuple pairscan be used as the key identifiers to which the charging ID (and policing 
5 authorization) is assigned or linked to, although the charging ID would be used for the 

identifier in CGR and billing. A call is triggered over the primary (signalling) PDP 
context by sending a call setup (in SIP: INVITE) message with logical channel 
information for the receiver side (i.e., the ports to which it is ready to receive real-time 

F f 

data. The CSCF receives the INVITE with SDP (with coded bandwidth and port 
10 information) and stores the information. The signalling is sent to the remote end, 

« 

which is answered (e.g., SIP 183 message) and the CSCF now receives a new set of 
SDP information with codec, bandwidth and terminating side destination ports 
provided by the remote end SDP. CSCF executed examination ofthe codec type data 
received from SIP messages from both terminals results in an agreed codec set, whose 

i \ 

1 5 destination [IP address, port] tuple values are known for each IP connection CSCF 

should authorise. 

The CSCF can use the CSCF-PCF-GGSN interfaces (or CSCF-GGSN if PCF 
is integrated to CSCF) to request policy control actions (bandwidth authorization) and 
charging coordination between layers.with the tuplesas keys. The GGSN admits the 

20 bandwidth and later during the secondary PDP context activation process, assigns the 

charging ID to the created PDP context associated with the key tuple values, and 
forwards the charging ID back to the CSCF for charging coordination purposes. The 
CSCF doesn't need to parse the Charging-ID from received SIP messages - there is no 
risk of malicious MT since it. won't be intercepting or modifying any SIP messages 

25 received from a TE. Instead it can correlate the charging ID sent by GGSN to the port 

information. 

The charging flexibility offered for the operator is further improved in the 

fourth embodiment if the TE sends a RE-INVITE message with changed QoS/codec 

< ' ■ \ 
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information, since the CSCF will notice outcome of the dynamic change in the 

i * 

i * v 

resulting signalling, and request new authorization and get a new charging ID. 

■ * p 

Furthermore, a new charging ID will be created to charging records for each new 
dynamically added real-time PDP context/media flow. If the real-time flows are to 
utilise RTP/UDP/1P header compression at the PDP layer, each media flow needs its 

■ 

own PDP context. Thus, operator charging can, if desired, follow the media changes 
(audio to videotelephony back to audio,. . .) within an end-to-end call. Following the 
process described in the third embodiment of this invention, the Call-ID would not 
change and would not indicate the media specific connection details in the charging 
information if, for example, SGSN and GGSN CDRs are omitted by an operator 
decision. 

It is to be noted that in the description of the invention above, numerous 

* » 

details known to those skilled in the art have been omitted for the sake of brevity. 
Such details are readily available in numerous publications including the previously 
cited protocols. 

i , 

i 

Although the present invention has been described with reference to a number 
of illustrative embodiments^ if should be understood that numerous other 

i 

modifications and embodiments can be devised by those skilled the art which will fall 
within the spirit and scope of the principles of this invention. More particularly, 
reasonable variations and modifications are possible in the component parts and/or 
arrangements of the subject combination arrangement within the scope of the 
foregoing disclosure, the drawings, and the appended claims without departing from 
the spirit of the invention. In addition to variations and modifications in the 
component parts and/or arrangements, alternative uses will also be apparent to those 
skilled the art. 
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WHAT IS CLAIMED IS: 

1 . A method for coordinating charging information in a communications 
network, the method comprising: .-, ! 

■ * ■ 

establishing a communication channel; 

associating a charging identification with said communication channel; and 

■ 

sending said charging identification from a first network element in the 

~* ■ • 

transport layer to a second network element in the application layer. 

2. The method of claim 1, wherein said second network element adds said 
charging identification to charging information which said second network element 
collects. 

3. The method of claim 1, wherein said first network element sends an 
address of a network element together with said charging identification to said second 
network element. 

4. The method of claim 3, wherein said second network element adds said 
address of a network element to charging information which said second network 
element collects. > . ■» i 

5. The method of claini 1 or 3, wherein said first network element sends 

» 

security information together with 1 said charging identification to said second network 

I 

element. 

6. The method of claim 5, wherein said second network element verifies said 
charging identification against said security information. 

7. The method of claim 1, wherein said communication channel is a Packet 
Data Protocol (PDP) context; - 

8. The method of claim 1, wherein said charging identification is a GGSN 

allocated Charging Id. 

9: The method of claim 1, wherein said first network element is a Mobile 

i ., : 

Station (MS). 

t 
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1 0. The method of claim I , wherein said first network element is a Serving 
GPRS Support Node (SGSN). 

1 1 . The method of claim I , wherein said first network element is a Gateway 
GPRS Support Node (GGSN). 

1 2. The method of claim 1 , wherein said second network element is a Call 
State Control Function (CSCF). 

13. The method of claim 9 or 12, wherein an SGSN sends said address of a 

■ 

network element to said first network element. 

14. The method of claim 9, 10, 1 1 or 12, wherein said address of a network 
element is an address of a GGSN. 

1 5. The method of claim 1 , wherein said transport layer is a GPRS/UMTS. 

16. The method of claim 1 , wherein said transport layer is a Packet Switched 

Core Network domain. 

17. The method of claim 1, wherein said application layer is a IP Multimedia 

Core Network domain. !■" i ; 

1 8. The method of claim 1, wherein said communication network is a packet 
switched wireless network. \ 

1 9. The method of claim 1 , wherein 

sending said charging identification is performed autonomously. 

20. The method of claim 1, wherein 

sending said charging identification is performed based on a request from said 
second network element. 

21. The method of claim 1, wherein said second network element sends said 
charging identification towards an endpoint of a communication. 
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22. The method of claim 2 1 1 wherein said second network element sends security 
information together with said charging identification toward said endpoint of a 
communication. 

23. The method of claim 2 1 , wherein said second network element sends an 
address of a network element together with said charging identification to said endpoint 
of a communication. 

24. The method of claim 9, wherein said second network element adds an address 
of said first network element to charging information which said second network element 
collects. 

25. A method for coordinating information between a transport layer and an 
application layer in a communications network, the method comprising: 

initiating a transaction in said application layer of a first network element; 
assigning an identification to said transaction; 

initiating a communication channel in said transport layer of said first network 
element; and , 

associating said communication channel with said transaction using said 

identification. 

26. The method of claim 25, wherein said identification is forwarded to a second 
network element in said application layer. ■ 

27. The method of claim 26, wherein said identification is forwarded to a third 
network element and a fourth network element in a transport layer. 

28. The method of claim 27, wherein charging information generated by said 
fourth network element and said third network element in said transport layer and by the 
second network element in said application layer is associated with said identification. 
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29. The method of claim 25, wherein said identification is a call identification of 
a SJP message. 

4 * 

30. The method of claim 26, wherein said second network element is a CSCF. 

3 1 . The method of claim 27, wherein said third network element is a SGSN and 
said fourth network element is a GGSN. 

* 

32. The method of claim 28, wherein said charging information is a CDR. 

33. The method of claim 25, wherein said communication channel is a Packet 
Data Protocol (PDP) context. 

34. The method of claim 25, wherein said transaction is a call. 

35. A system for coordinating information between an application layer and a 
transport layer in a communication network, the system comprising; 

means for initiating a transaction in said application layer of a first network 
element; 

means for assigning an identification to said transaction; 

means for initiating a communication, channd in said transport layer of said first 

< 

network element; and 

means for associating said communication channel with said transaction using 

said identification. 

36. A method for coordinating charging information in a communications 
network, the method comprising: 

establishing a communication connection; 

generating a globally unique charging identification in a first network element and 
associating said globally unique charging identification with said communication 
connection; and »■■■■. 
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sending said globally unique charging identification from said first network 
element to a second network element. 

37. The method of claim 36, wherein said second network element uses said 
globally unique charging identification to collect charging information. 

38. The method of claim 36, wherein said globally unique charging identification 
includes the address of the first network element. 

39. The method of claim 36, wherein said communication channel is a Packet 

i ' 

Data Protocol (PDP) context. 

40. The method of claim 36, wherein said globally unique charging 
identification is generated by a GGSN. 

41 . The method of claim 36, wherein said first network element is a Mobile 

Station (MS). 

42. The method of claim 36, wherein said first network element is a Serving 
GPRS Support Node (SGSN). ' " \! *\ 

43. The method of claim 36, wherein said first network element is a Gateway 
GPRS Support Node (GGSN). 

44. The method of claim 36, wherein said second network element is a Call State 

Control Function (CSCF). 

45. The method of claim 36, wherein/said second network element sends said 
globally unique charging identification towards an endpoint of a communication. 

46. The method of claim 45, wherein said.second network element sends said 
globally unique charging identification to a second network. 

47. The method of claim 45, wherein said second network collects charging 

I L • 

data using said globally unique charging identification and prepares billing using the 
collected charging data. 
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48. the method of claim 47, wherein said second network collects 
charging data from a plurality of call detail records associated with said globally 
unique charging identification. 

49. A method for coordinating information between a transport layer and 
an application layer in a communications network, the method comprising: 

initiating a transaction in said application layer of a first network element; 
assigning a tuple or tuple pair for each communication connection within said 
transaction; 

initiating at least one communication connection in said transport layer of said 
first network element; and 

associating said at least one communication connection with said transaction 
using said tuple or tuple pair. , 

50. The method of claim 49, wherein said tuple or tuple pair is forwarded to a 
second network element in said application layer, 

51. The method of claim 50, wherein said tuple or tuple pair is forwarded to a 
third network element and a fourth network element in a transport layer. 

52. The method of claim 51, wherein charging information generated by said 
fourth network element and said third network element in said transport layer and by 
the second network element in said application layer is associated with said tuple or 
tuple pair, 1 

53. The method of claim 49, wherein said tuple includes a destination IP 
address and port information of a transaction specific media connection. 

54. The method of claim 50, wherein said second network element is a CSCF. 

i i ... 

55. The method of claim 51, wherein said third network element is a SGSN 
and said fourth network element is a GGSN. 
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56. The method of claim 52, wherein said charging information is a CDR, 

57. The method of claim 49, wherein said communication connection is a Packet 
Data Protocol (PDP) context. 

58. The method of claim 49, wherein said transaction is a call. 

59. A system for coordinating information between an application layer and a 
transport layer in a communications network, the system comprising: 

means for initiating a transaction in said application layer of a first network 
element; 

means for assigning a tuple or tuple pair to said transaction; 

means for initiating at least one communication connection in said transport layer 
of said first network element; and 

means for associating said at least one communication connection with said 
transaction using said tuple or tuple pair. 

: . h • 

» 

l 
i 
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Foreword 

This Technical Specification has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: " ' 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the overall high level functionality and architecture impacts of Flow Based Charging. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



■ \ 

[1] 3GPP TR 41.001 : "GSM Release specifications". 

. • < . 

[2] 3GPP TS 2 1 .905: "Vocabulary for 3GPP Specifications". 

[3] 3GPP TS 32.200: "Charging Principles". 

[4] 3GPP TS 23.228: "IP Multimedia (IM) : Subsystem - Stage 2". 

[5] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[7] 3GPP TS 32.225: 'Telecommunication management; Charging management; Charging data 

description for the IP Multimedia Subsystem (IMS)". 

[8] 3 GPP TS 23.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL); 

Stage 2". 

i > 

3 Definitions, symbols and abbreviations 

3.1 Definitions 



For the purposes of the present document, the' terms 'and, definitions' given in TS 21.905 [2] and in TS 32.225 [7] and the 
following apply: 

Charging key: information used by the online and offline charging system for rating purposes. 

Charging rule: a set of information comprising the service data flow filters, charging key, and the associated charging 
actions, for a single service data flow (further details can be found iri 4.3). 

* 

I « ■ . s . ' • I 

Dynamic charging rule: Charging rule where some of the data within the charging rule (e.g. service data flow filter 
information) is assigned via real-time analysis, which may use dynamic application derived criteria. 

Packet flow: a specific user data flow carried through the Traffic Plane Function. A packet flow can be an IP flow. 

Predefined charging rule: Static charging rule which is defined in the Traffic Plane Function. 
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Service data flow: aggregate set of packet flows. In the case of GPRS, it shall be possible that a service data flow is 
more granular than a PDP context. ■! ■ 

Service Data Flow Filter: a set of filter parameters used to identify one or more of the packet flows constituting a 
service data flow. At least the following means for the packet flow identification shall be supported: source and 
destination IP address+port, transport protocol, or application protocol. 

Static charging rule: Charging rule where all of the data within the charging rule describing the service data flow is 
permanently configured throughout the duration of a user's data session. A static charging rule may be activated 
dynamically. 

3.2 Symbols 

• V « " " ! ' ' • 

' . • ! • • . it , 

For the purposes of the present document, the following symbols apply: 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AF 


Application Function . 


CCF 


Charging Collection Function 


CDR 


Charging Data Records ,j 


CRF 


Charging Rules Function 


CSCF 


Call Session Control Function 


FBC 


Flow Based Charging 


FTP 


File Transfer Protocol 


G-CDR 


GGSN generated CDR 


GGSN 


Gateway GPRS Support Nodei : 


GPRS 


General Packet Radio Service 


gsmSCF 


GSM Service Control Function 1 : 


HPLMN 


Home PLMN 


HTTP 


Hypertext Transfer Protocol 


I-CSCF 


Interrogating CSCF 


IM 


IP Multimedia 


IMS 


IP Multimedia Core Network Subsystem 


IMSI 


International Mobile Subscriber Identity 


OCS 


Online Charging System * 


P-CSCF 


Proxy-CSCF 


PDG 


Packet Data Gateway 


PLMN 


Public Land Mobile Network 


QoS 


Quality of Service t 


SAI 


Service Area Identity ' 


S-CDR 


SGSN generated CDR 


S-CSCF 


Serving-CSCF , 


SBLP 


Service Based Local Policy 


SDF 


Service Data Flow , , , 


SGSN 


Serving GPRS Support Node 


SIP 


Session Initiation Protocol 


TPF 


Traffic Plane Function 


UE 


User Equipment 


WAP 


Wireless Application Protocol 


WLAN 


Wireless LAN 
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4 General Requirements 

■ 

4.1 General 

The current level of traffic differentiation and traffic-type awareness of the GPRS architecture shall be extended beyond 
APN and PDP Context level. It shall be possible to apply differentiated charging for the traffic flows belonging to 
different services (a.k.a. different service data flows) even if they use the same PDP Context. 

In addition, it shall be possible to apply differentiated charging for the traffic flows belonging to different services 
carried by other IP Connectivity Access Networks (IP-CANs). 

Charging and tariffing models described in this Technical Specification shall be possible to be applied to both prepaid 
and postpaid subscribers, i.e. to both online and offline charging. 

■ ■ 

Online and offline are not the same as prepaid and postpaid (see TS 32.225 [7]). For example it is worth highlighting 
that the operator can have postpaid subscribers on credit control by using on-line charging mechanisms. 

The GPRS online charging solutions up to release 5 are built around CAMEL mechanisms that provide online access- 
and charging-control for GPRS - pertaining to PDP Contexts of an APN. 

The flow based charging architecture developed in this Technical Specification shall use generic native IP charging 
mechanisms to the extent possible in order to enable the reuse of the same charging solution and infrastructure for 
different type of IP-Connectivity Networks. 

i • 
Note: Providing differentiated service data flow based charging is a different function from providing 

differentiated traffic treatment on the IP-flow level. The operation of service data flow based charging 
shall not mandate the operation of service based local policy. 

In addition charging based on specific application services or protocols shall be supported. 

4.2 Backwards compatibility 

■ 

i 

The capabilities of the enhanced architecture introduced' with flow based charging shall be backwards compatible with 
the release 5 charging capabilities. These new functions shall be compatible and coherent with the authentication, 
authorization, PDP context management, roaming and other functions provided by the release 5 architecture. 

It shall be possible to collect data volumes pier PDP context foruse in billing and operational management systems. 

It shall be possible to derive data volumes, which are not subject to service data flow based charging. The data volumes 
may be charged according to the GPRS mechanisms. 

■ 

4.3 Charging models 

4.3.1 General 

When developing the charging solutions, the following charging models should be considered, even though the full 
solution to support the models may not be within the scope of this TS. 

Shared revenue services shall be supported. In this case settlement for all parties shall be supported, including the third 
parties that may have been involved providing the services. 

fit' i • 

The charging solution shall allow various charging models such as: 

- Volume based charging; ' ' < ! , 

- Time based charging. ; ■ * . 

Editor's note: Additional charging models that are event and service based require further investigation. 
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It shall be possible to apply different rates when a user is identified to be roaming from when the user is in the home 
network. 

It shall be possible to restrict special rates to a specific service, e.g. allow the user to download a certain volume of data 
from one service for free, but this allowed volume is not transferable to other services. It shall be possible also to apply 
special rates based on the time of day. 

It shall be possible to enforce per-service usage limits for a service data flow using online charging on a per user basis 
(may apply to pre-paid and postpaid users).. >. > <v 

In the case of online charging, and where information is available to enable service data flow packets to be associated 
with a specific PDP context, it shall be possible to perform rating and allocate credit depending on the characteristics of 
the resources allocated initially (in the GPRS case, the QoS of the PDP context). 

< : : i i 

i 

The flow based bearer level charging can support dynamic selection of charging to apply. A number of different inputs 
can be used in the decision to identify the specific charging to apply. For example, a service data flow may be charged 
with different rates depending on what QoS is applicable. The charging rate may thus be modified when a bearer is 
created or removed, to change the QoS provided for a service data flow. 

The charging rate or charging model applicable to a service data flow may also be changed as a result of events in the 
service (e.g. insertion of a paid advertisement within a user requested media stream). The charging model applicable to 
a service data flow may also change as a result of events identified by the OCS (e.g. after having spent a certain amount, 
the user gets to use some services for free). 

In the case of online charging, it shall be possible to apply an online charging action upon TPF events (e.g. re- 
authorization upon QoS change). 

4.3.2 Examples of Service Data Flow Charging 

There are many different services that may be used within a network, including both user-user and user-network 
services. Service data flows from these services may be identified and charged in many different ways. A number of 
examples of configuring charging rules for different 'service data flows are described below. 

• ' ■ • '4 

A network server provides an FTP service. The FTP server supports both the active (separate ports for control and data) 
and passive modes of operation. A charging rule is configured for the service data flows associated with the FTP server 
for the user. The charging rule uses a filter specification for the uplink that identifies packets sent to port 20 or 21 of the 
IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter specification 
identifies packets sent from port 20 or 2 1 of the IP address of the server. 

* l ' . * * 

A network server provides a "web" service. 'A charging rule is configured for the service data flows associated with the 
HTTP server for the user. The charging rule uses a filter specification for the uplink that identifies packets sent to port 
80 of the IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter 
specification identifies packets sent from port 80 of the IP address of the server. 

The same server also provides a WAP service. The server has multiple IP addresses, and the IP address of the WAP 
server is different from the IP address of the web server. The charging rule uses the same filter specification as for the 
web server, except the IP address is different. 

An operator offers a zero rating for network provided DNS service. A charging rule is established setting all DNS 
traffic to/from the operators DNS servers as offline charged. The data flow filter identifies the DNS port number, and 
the source/destination address within the subnet range allocated to the operators network nodes. 

i : 

An operator has a specific charging rate for user-user VoIP traffic over the IMS. A charging rule is established for this 
service data flow. The filter information to identify the specific service data flow for the user-user traffic is provided by 
theP-CSCF. 



1 • . . : 

Release 6 11 " 3GPPTS 23.125 V6.0.0 (2004-03) 



5 Flow Based Charging Concepts 



5.1 Overview 



i. 



Editor's note: This clause is planned to contain the relevant descriptions of the overall function for the flow based 
charging. 

The following functions are provided by the network for service data flow based charging. This applies to both online 
and offline charging unless otherwise specified: 

- Identification of the service data flows that need to be charged individually (e.g. at different rates); 

- Provision and control of charging rules on service data flow level; 

- Reporting of service data flow level byte counts; 

Event indication according to on-line charging procedures (e.g. sending AAA Accounting Stop) and, optionally, 
following this particular event, taking appropriate actions on service data flow(s) according to the termination 
action. 

Event indication and event monitoring by the TPF and following this particular event, taking the appropriate on- 
line charging actions. 



5.2 Charging rules 



, l| | F i » i 



■ i 

Charging rules contain information that allow for filtering of traffic to identify the packets belonging to a particular 
service data flow, and allow for defining how the service data flow is to be charged. The following apply to charging 
rules: 

- The charging rules for bearer charging are defined by the operator. 

- These charging rules are made available to the Traffic Plane function for both offline and online charging. 

- Multiple charging rules are supported simultaneously per user. 

- Filtering information within a charging rule is applied through filtering functionality at the Traffic Plane 
Function to identify the packets belonging to a particular service data flow. 

i 

- Charging rules with dynamically provisioned filtering information (i.e. made available to the Traffic Plane 
Function) are supported in order to cover IP service scenarios where the filtering information is dynamically 
negotiated (e.g. negotiated on the applicaitibrrleVel (e.g! IMS)): 

- Pre-defined charging rules are supported. . 

- Elements of charging rules may be statically configured at the Traffic Plane Function, or dynamically 
provisioned. 

Note-i: The mechanism to support use of elements statically pre-defined in the TPF (e.g. filter information) is for 
stage 3 development. 

Note-ii: The stage 3 development may also evaluate providing an pptimisation to support dynamic provisioning of 
an entire charging rule pre-defined in the TPF. 

- Pre-defined filters may support extended capabilities, including enhanced capabilities to identify packets 
associated with application protocols. , j , 

- There may be overlap between the charging rules that are applicable. Overlap can occur between: 

- multiple pre-defined charging rules in the TPF; 



Release 6 



12 



3GPP TS 23.125 V6.0.0 (2004-03) 



- charging rules pre-defined in the TPF and rules from the Service Data Flow Based Charging Rules 
Function, which can overlay the pre-defined rules in the TPF. 

The precedence identified with each charging rule shall resolve all overlap between the charging rules. When 
overlap occurs between a dynamically allocated charging rule and a pre-defined charging rule at the TPF, and 
they both share the same precedence, then the dynamically allocated charging rule shall be used. 

- Charging rules contain information on:':. • . f ' 

* 

- How a particular service data flow is to be charged: online/offline; 

- In case of offline charging whether to record volume- or time-based charging information; 

- Charging key; . 

- Service data flow filter(s); 

V 

- Precedence. i 

- Once the charging rule is determined it is applied to the service data flow at the Traffic Plane Function and 
packets are counted and categorised per the rule set in the charging rule. 

- Separate charging rules can be provided for downlink and uplink. 

- Charging rules can be configured for both user initiated and network initiated flows. 

- Charging rules can change and be overridden, 1 e.g. for a previously established PDP context in the GPRS case, 
based on specific events (e.g. IM domain events or GPRS domain events, credit control events). 

- Different charging rules can be applied for different users or groups of users. 

- Different charging rules can be applied based on the location of the user (e.g. based on identity of the roamed to 

~~ '■...* • 

network). . . ; .;■ >..*.; 

- For GPRS, charging rule assignment can occur at PDP context establishment and modification. 

- For GPRS, the charging rules can be dependent on the APN used. 

t ■ i 

5.3 Service data flow filters and counting 

This section refers to the filtering that identifies the service data flows that need to be charged individually (e.g. at 
different rates). Basic example: look for packets of one service, e.g. to and from a server A. 

■ 

- Separate filtering and counting can be applied for downlink and uplink. 

- Different granularity for service data flow filters identifying the service data flow is possible e.g. 

■i 

- Filters based on the IP 5 tuple (source IP address, destination IP address, source port number, destination 
port number, protocol ID of the protocol above IP). Port numbers and protocol ID may be wildcarded. IP 
addresses may be wildcarded or masked by a prefix mask. 

- Special filters which look further into the packet, or/require other complex operation (e.g. maintaining 
state) may be pre-defined in the TPF and invoked by the CRF using standardised means. Such filters may 
be used to support filtering with respect to a service data flow based on the transport and application 
protocols used above IP. This shall be possible for HTTP and WAP. This includes the ability to 
differentiate between TCP, Wireless-TCP according to WAP 2.0, WDP, etc, in addition to differentiation 
at the application level. Filtering fbr further application protocols and services may also be supported. 

- In the case of GPRS, the traffic plane function supportsslmultaneous independent filtering on service data flows 
associated with all, and each individual active PDP contexts; that is, primary and secondary PDP contexts, of one 
APN. 

« 

- In case of no applicable filters for a service data flow, an operator configurable default charging should be 
applied. The default charging may use accounting information provided by FBC, or may use accounting 



, ' : '.iii: nS' \Vi' 
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information provided by other charging. mechanisms available for the IP-Connectivity Access Network (e.g. 
existing GPRS charging mechanisms). 

The service data flow filters and counting are applied, by the TPF (the GGSN in the case of GPRS). 
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Figure 5.1 - Relationship of service data flow, packet flow and service data flow filter 



5.4 



Reporting 



This refers to the differentiated charging information being reported to the charging functions. Basic example: those 20 
packets were in rating category A, include this in your global charging information. 

J 

- The Traffic Plane function shall report bearer charging information for online charging; 

- The Traffic Plane function shall report bearer charging information for offline charging; 

- Charging information is reported based on the, application of the bearer charging rules in the TPF (service data 
flow related charging information), and in the case of GPRS, as specified in [3] (per PDP context); 

- It shall be possible to report charging information showing usage for each user for each charging rule, e.g. a 
report may contain multiple containers, each coih'tainer associated with a charging key; 

- It shall be possible to associate per PDP context charging information with the corresponding service data flow 
based charging information. It shall be possible to derive or account the data volumes per PDP context for traffic 
not accounted via any applicable charging rule. 

For example, in the case of GPRS, output of FBC data per charging rule on a per PDP context basis would allow 
non-FBC charged data volumes to be determined, and existing GPRS charging mechanisms to be applied. 

Editor's Note: How online GPRS charging can be supported for packets not accounted by FBC is FFS. 



5.5 



Credit management 



In case of online charging, it shall be possible for the OCS to apply re-authorisation of credit in case of particular events 
e.g. credit authorisation lifetime expiry, idle timeout, GPRS events such as SGSN change, QoS changes. 

In case of online charging, credit can be pooled for multiple (one or more) charging rules applied at the Traffic Plane 
Function. A pool of credit applying to a single charging rule ! is equivalent to an individual credit limit for that charging 
rule. Multiple pools of credit shall be allowed per user. 
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■ 

» * ■ 

, i . ■ , t 

Rating decisions shall be strictly controlled by the OCS for each service. The OCS shall also control the credit pooling 
decision for charging rules. The OCS shall either provide a new pool of credit, together with a new credit limit, or a 
reference to a pool of credit that already exists at the TPF. 

The grouping of charging rules into pools in this way shall not restrict the ability of the OCS to do credit authorisation 
and provide termination action individually for each charging rule of the pool. 

Note: 'credit' as used here does not imply actual monetary credit, but an abstract measure of resources available 
to the user. The relationship between this abstract measure, actual money, and actual network resources or 
data transfer, is controlled by the OCS. 

It shall be possible for the OCS to group flows charged at different rates or in different units (e.g. time/volume). 

* 

■ ■ ■ ' s 

Editor's note: Any impact of this requirement in relation to operation of the Gy needs to be investigated. 

5.6 Termination Action 

i 
I 

The Termination Action applies only in case of online charging. The termination action indicates the action, which the 
Traffic Plane Function should perform when the online charging system indicates the credit for the service data flow 
has expired. ' " 1 

The defined termination actions include: 

1 i ' . ■ 

- Dropping the packets corresponding to a terminated service data flow as they pass through the Traffic Plane 
Function; 

i 

i 

- A termination action may indicate to the TPF that the default termination behaviour shall be used; 

- The re-directing of packets corresponding to a terminated service data flow to an application server (e.g., defined 

in the termination action). ' ■ ■ ■ »> -•• . ■•'.■>: 

. » 

' t . • 1 ' ^ . VT *r « I , » 

Note: such a re-direction may cause ah application protocol specific asynchronous close event and application 
protocol specific procedures mayibe required in 1 the UE and/or Application Function in order to recover, 
e.g., as specified in RFC 2616 for HTTP. 

Default termination behaviour shall be pre-configured in the TPF according to operator's policy. For instance, a default 
behaviour may consist of allowing packets of the corresponding. service data flow to pass through the TPF. 

The OCS may provide the termination action over the Gy interface. 

The Termination Action may trigger other procedures, e.g. the deactivation of a PDP context or the termination of a 
WLAN session. 



6 Architectural concepts 

6.1 Architecture 

< < 

t 

Editor's note: This clause is planned to contain the relevant part of the architecture impacted by IP flow level based 
charging. 

6.1 .1 Online service data flow based bearer charging architecture 

♦ • 

Figure 6.1 below presents the overall architecture for service data flow based online bearer charging. 
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Figure 6.1: Overall architecture for service data flow based online bearer charging 

Note(*): The detailed functional entities of the Online Charging System are not shown in this figure. The details of 
the OCS are specified in [3]. . 

The CAMEL-SCP depicted on the figure above performs the functions as defined in [8]. 

6.1 .2 Offline service data flow based bearer charging architecture 

Figure 6.2 below presents the overall architecture for service data flow based offline bearer charging. 
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Figure 6.2: Overall architecture for service data flow based offline bearer charging 

Note: The CCF depicted on the figure above performs the functions as defined in [3]. 
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* i 
, 1 

6.2 Functional Entities 

i * ■ t 

6.2.1 Service Data Flow Based, Charging Rules Function 

The Service Data Flow Based Charging Rules Function provides service data flow level charging rules. This 
functionality is required for both offline and online charging. The Service Data Flow Based Charging Rules Function 
accesses information stored in the service data flow based charging rules data repository. An external interface to the 
charging rules data repository may be used for management of the charging rules within the data repository. 
Specification of interfaces to the data repository is out of scope of this TS. 

The service data flow based charging rules function supports both static and dynamic charging rules. 

The service data flow based charging rules function determines, what charging rules (including precedence) to apply for 
a user. The applicable charging rules are determined based on information available to the CRF including that received 
from the Traffic Plane Function, i.e. information about the user, the bearer characteristics and whether it is an initial 
request or not. When a further request for charging rules from the Traffic Plane Function or information from an AF 
arrives the service data flow based charging rules function shall be able to identify whether new charging rules need to 
be transferred to the Traffic Plane Function and respond accordingly. 

The service data flow based charging rules function will receive information from the application function that allows a 
service data flow to be identified, and this information may be used within the charging rule (i.e. protocol, IP addresses 
and port numbers). Other information that is received by the service data flow based charging rules function (i.e. 
application identifier, type of stream) may be used in order to select the charging rule to be applied. 

, ■ 

A CRF node may serve multiple TPFs. ■ ; ■ ' 

6.2.2 Service Data Flow Based Credit Control Function 

The Service Data Flow Based Credit Control Function performs online credit control functions together with the Online 
Charging System. It provides a new function within the Online Charging System. 

The Online Charging System is specified in 3GPP TS 32.200 [3]. The Service Data Flow Based Credit Control 
Function is considered as a new functional entity for release 6 within the Online Charging System. 

The OCS can interact with the CRF, by using 4he Ry, interface: This allows the OCS to provide input to the CRF for 
charging rules selection. t , 

6.2.3 Charging Collection Function 

The Charging Collection Function is specified in 3GPP TS 32.200 [3]. - 

6.2.4 Traffic Plane Function , 

The Traffic Plane Function shall be capable of differentiating user data traffic belonging to different service data flows 
for the purpose of collecting offline charging data and performing online credit control. 

The Traffic Plane Function shall support pre-defined charging rules, and pre-defined filters. See subclause 5.3 for 
further filtering and counting requirements. 

For online charging, the Traffic Plane Function shall be capable of managing a pool of credit used for some or all of the 
service data flows of a user. The Traffic Plane Function shall also be capable of managing the credit of each individual 
service data flow of the user. > ; \ 

■ ■ 

A TPF may be served by one or more CRF nodes. The appropriate CRF is contacted based on UE identity information. 

Editor's note: The specific identity information used toidentify the appropriate CRF is FFS. 

For GPRS, it shall be possible to provide flow based charging functions for different service data flows even if they are 
carried in the same PDP Context. For GPRS^the^traffic^lahe Function is a logical function allocated to the GGSN. 
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Editor's Note: The effects of this co-location to the interfaces still needs to be studied e.g. Gy, Gz, Gi. Gi radius 
extensions for charging purposes are hot precluded. 

For GPRS, the TPF/GGSN shall be able to do separate counts per PDP context for a single service data flow if it is 
transferred on more than one PDP context. ' 

Editor's note: How this can be achieved is FFS. 

! i , ' 

For each PDP context, the TPF shall accept information during bearer establishment and modification relating to: 

- The user and terminal (e.g. MSISDN, IMEISV) 

- Bearer characteristics (e.g. QoS negotiated, APN) 

• i • ? 

r . * 

I 

- Network related information (e.g. MCC and MNC) 

* * < 

The TPF may use this information in the OCS request/reporting or request for charging rules. 

i 

i 

For each PDP context, there shall be a separate OCS request/reporting, so this allows the OCS and offline charging 
system to apply different rating depending pri the PDP,cc)ntext. 

The Traffic Plane Function shall identify packets that are charged 'according to service data flow based charging. The 
Traffic Plane Function shall report the data volume(s) charged according to service data flow based charging. In case of 
GPRS, the Traffic Plane Function shall report the service data flow based charging data for each charging rule on a per 
PDP context basis. 

i 

At initial bearer establishment the Traffic Plane Function shall request charging rules applicable for this bearer from the 
charging rules function. As part of the request, the Traffic Plane Function provides the relevant information to the 
charging rules function. The Traffic Plane Function shall use the charging rules received in the response from the 
charging rules function. In addition, the Traffic Plane Function shall use any applicable pre-defined static charging 
rules. Pre-defined charging rules may apply for all users or may be activated by the CRF. 

If the bearer is modified by changing the bearer characteristics relevant for the selection of the charging rules, the 
Traffic Plane Function shall request charging rules for the new bearer characteristics from the charging rules function. 

If the Traffic Plane Function receives an unsolicited update of the charging rules from the charging rules function, the 
new charging rules shall be used. 

■ 

If another bearer is established by the same user (e.g; for GPRS a secondary PDP context), the same procedures shall be 
applied by the Traffic Plane Function as described for the initial bearer. 

The Traffic Plane Function shall evaluate received packets against the service data flow filters in the order according to 
the precedence for the charging rules. When a packet is matched against a SDF filter, the packet matching process for 
that packet is complete, and the charging rule for that SDF filter shall be applied. 

• , ' WW '< l.tf ' '• 

6.2.5 Application Function ' 

; ■ ( i • 

The Application Function provides information to the service data flow based charging rules function, which can then 
be used for selecting the appropriate charging rule, and also used for configuring some of the parameters for the 
charging rule. The operator configures the charging rules in the service data flow based charging rules function, and 
decides what data from the application function shall' be used in the charging rule selection algorithm. 

An AF may communicate with multiple CRFs. The AF contacts the appropriate CRF for a user at any time based on UE 
identity information. \ , . 

i . ■ 

Editor's note: The specific identity information used to identify the appropriate CRF is FFS. 

The Application Function shall provide information to allow the, service data flow to be identified. The Application 
Function shall also provide some other information that may be used in the charging rule selection process. 

The information provided by the application function is as follows: 

- Information to identify the service data flow: refer to subclause 5.3. 

The application function may use wildcards to identify an aggregate set of IP flows. 
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- Information to support charging rule selection: 

- Application identifier; 

- Application event identifier;. 

i 

- Type of Stream (e.g. audio, video), (optional); . 

- Data rate of stream (optional). 

Editor's Note: Additional information is FFS. 

The "Application Identifier" is an identifier associated with each service that an AF provides for an operator (e.g. a 
packet streaming service application function would have one application identifier for the service). 

The "Application event identifier" is an identifier within an Application identifier. It is used to notify the Service Data 
Flow Based Charging Rules Function of such a change within a service session that affects the charging rules, e.g. 
triggers the generation of a new charging rule. 

6.2.6 Relationship between functional entities 

The AF and the CRF need not exist within the same operator's network. The Rx interface may be intra- or inter-domain 
and shall support the relevant protection mechanisms for an inter-operator or third party interface. 

Editor's note: It is for further study how charging rules from a home network can be supported when the TPF is in 
the visited network (e.g. CRF in home network communicating via CRF in visited network, CRF in home 
network communicating to TPF in visited network). 

6.3 Reference points 

..•..ivv'iif'u', •: 
6.3.1 Gx reference point 

■ 

The Gx reference point enables the use of service data flow based charging rules such as counting number of packets 
belonging to a rate category in the IP-Connectivity Network. This functionality is required for both offline and online 
charging. , ■ 

Note: The reuse of existing protocols over the Gi reference point for Gx shall be evaluated in stage 3. 

"I:'-.}' 

The Gx reference point supports the following functions: 

* * . . 

■ 

1 . Initialisation and maintenance of connection 

2. Request for Charging Rules (from TPF to CRF) ! - 

3 . Provision of Charging Rules (from CRF to TPF) 

4. Indication of Bearer Termination (from TPF to CRF) 

6.3.1 .1 Initialisation and Maintenance of Connection 

< ■ 

A single connection shall be established between each interworking CRF and TPF pair. The connection can be direct, or 
established via a relay/proxy node. A connection may be redirected to an alternate node. 

At a failover, commands which have not been successfully received shall be queued to the alternate peer. 

The detail specification of the connection establishment and maintenance is for specification in stage 3. 

. ! . 

! 

6.3.1 .2 Request for Charging Rules (from TPF to CRF) 

* ' * • 

At a bearer establishment/modification (PDP, context establishment/modification for GPRS), the TPF requests the 
charging rules to be applied. 
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The request must identify whether it is an initial request (primary context establishment for GPRS), or a subsequent 
request (i.e. for GPRS, a secondary PDP context establishment, or a PDP context modification). For an initial request 
for GPRS, the request shall include APN, PDP address information, and at least one of IMSI or MSISDN. Other 
relevant network and terminal information should also be included. 

Editor's Note: Where the relevant network and terminal information is defined is FFS (either in this TS or 32.xyz). 

. r 

An identifier is required to allow the specific instance in the TPF/CRF to be identified for subsequent data exchange. 
The identifier for the communication must be provided. 

The request must provide further information used for the charging rule selection. The request shall include an identifier 
for the bearer, the QoS information, and flow identifier information allocated to the bearer. For GPRS, this information 
would include the traffic class, and the TFT. 

' : 

P 

I 

Where the charging rule selection data for a bearer is modified, the TPF sends the request to the CRF indicating it is for 
a bearer modification, and providing the modified data/ ; 

6.3.1 .3 Provision of Charging Rules (from CRF to TPF) 

The CRF identifies the charging rules that are applicable to the TPF. The CRF then sends the charging rule information 
to the TPF to be installed. 

Note: The stage 3 development shall support provisioning cases where: 

* » 

- charging rules are to be installed in the TPF; , . . , . 

i 

- charging rules are to be removed in the TPF; 

- charging rules are to be installed and removed in the TPF; 

- charging rules are neither installed nor removed in the TPF (only relevant in the response to a request for 
charging rules). 

The provisioning may be a response to a Request for. Charging Rules, or it may be unsolicited. 

The charging rule provision includes information about the instanceit relates to (i.e. identifier for the relevant CRF/TPF 
instance), charging mechanism (online/offline), volume- or time-based charging indication, charging key, service data 
flow filter(s), and precedence. 

The service data flow filters are specified separately for the). uplink and downlink direction. 

• .. r f*i t it I'll. '*" - 

Note: A charging rule may provide information for service data flows for one direction, or for both directions. 

6.3.1 A Indication of Bearer Termination (from TPF to CRF) 

The TPF indicates to the CRF that a bearer is terminated. ; . . 

The bearer termination indication includes information to. identify the instance it relates to (i.e. an identifier for the 
relevant CRF/TPF instance), and an indication of . the bearer being removed (the PDP context in the case of GPRS). The 
termination also indicates if this is the last bearer for that TPF/CRF instance. 

) I ■ ■ 

6.3.2 Gy reference point 

* . *' 
p 

The Gy reference point allows credit control for service data flow based online charging. The functionalities required 
across the Gy reference point use functionalities and mechanisms specified for the release 5 Ro interface. 

The Ro interface is specified for release 5 in TS 32.200 [3] and TS 32.225 [7], 

6.3.3 Gz reference point 1 

The Gz reference point enables transport of service data flow based offline charging information. 
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For GPRS the relationship of the Gz reference point and the existing Ga interface is subject to investigation in SA5. 

• > ■ 

The Ga interface is specified by TS 32.200 [3]. • ' 5 ' * ' * \ 

6.3.4 Rx reference point 



6.3.4.1 



General 



The Rx reference point enables transport of information (e.g' : dynamic media stream information) from the application 
function to the charging rules function. An example of such information would be filter information to identify the 
packet flow. 



6.3.4.2 



Initialisation and Maintenance of Connection 



A single connection shall be established between each interworking CRF and AF pair. The connection can be direct, or 

established via a relay/proxy node. A connection may be redirected to an alternate node. 

> . '. • 

At a failover, commands which have not been successfully received shall be queued to the alternate peer. 
The detail specification of the connection establishment and maintenance is for specification in stage 3. 

6.3.5 Ry reference point 



The Ry reference point enables transport of information (e.g. charging rules selection information) from the OCS to the 
charging rules function. The functionality supportedWe'r'the Ry reference point should be the same as for the Rx 
reference point and a common interface specification is expected. 



7 



Message Flows 



Editor's note: This clause is planned to contain the description ,of new and modified information flows, 



7.1 



AF input to provision of charging rules 



The AF may provide the CRF with application/service data flow charging information. This information is used by the 
CRF to determine and complete the appropriate charging rules to send to the TPF. It is an AF decision when to send this 
information and the CRF takes the AF input into account from the point that it receives the AF information. 



CRF 



AF 



l.Send 

• > 

application/service 
data flow charging 



. information 

J ' i > • .ill' ! \ 



« \ 'I 



2. Ack 



1 . The AF sends application/service data flow charging information 

2. The CRF acknowledges the AF input. ' • ■ 
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7.2 



Bearer events 



7.2.1 Bearer Service Establishment 



UE TPF 

1 . Establish Bearer Serv Red 



CRF 



r • 

: f • ..... t. . 1 

• ' . • ! • 



i 

2. Request charging rules 



3. Identify charging 
rules to install 



4. Provision Charging Rules 



5. Install/Remove 
charging rules . 



6. Establish Bearer Serv 



Accept 



Figure 7.1: Bearer Service Establishment 



The TPF receives a request to establish a bearer service. For GPRS, this is the GGSN that receives a Create PDP 
context request for a primary or secondary PDP context. 

The TPF requests the applicable charging. ruleV and provides relevant input information for the charging rule 
decision. 



3 The CRF determines the charging rules to be provisioned, based on information available to the CRF (e.g. 
information may be available from the AF as described in 7.1 and the new information received from the TPF). 
Charging rules may need to be added, and/or removed. ( 

4 The CRF provides the charging rules to the TPF. This i message is flagged as the response to the TPF request. 

5 The TPF installs/removes the charging rules as indicated. • 

« T 

6 The TPF continues with the bearer service establishment procedure. 



Editors Note: It is FFS whether the bearer service establishment procedure can proceed in parallel with- the 
charging rules request. . 
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7.2.2 Bearer Service Modification 



UE TPF 

1 . Modify Bearer Serv Req 



CRF 



2. Request charging rules 



3. Identify charging 
rules to apply 



4. Provision Charging Rules 



5. Install/Remove 
charging rules 



6. Modify Bearer Serv Accept 

l± ; ; a* 



Figure 7.2: Bearer Service Modification 

i 

1 The TPF receives a request to modify a bearer service. For GPRS, the GGSN receives an Update PDP context 
request. 

2 The TPF requests the applicable charging rules, and provides relevant input information for the charging rule 
decision. 

3 The CRF determines the charging rules to be provisioned, based on information available to the CRF (e.g. 
information may be available from the AF as described in 7.1 and the new information received from the TPF). 
Charging rules may need to be added, and/or removed. 

4 The CRF provides the charging rule information to the TPF. This message is flagged as the response to the TPF 
request. 



5 The TPF installs/removes the charging rules as indicated. 

6 The TPF continues with the bearer service modification procedure. 

Note: In the case of GPRS, the modification of the bearer service may also be initiated by other nodes such as 
theSGSN. ..-.].,■■ :•" • 

• . : J • 

Editor's Note: It is FFS whether the lieirer service 1 modification procedure can proceed in parallel with the 
charging rules request. . 
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7.2.3 Bearer Service Termination 



i 



UE 



TPF 



CRF 



1. Remove Bearer Serv Req 



i 

» ; 



2. Indication of Bearer Termination 



3. Identify charging 
rules to apply 



4. Provision Charging Rules 



5. Install/Remove 
charging rules .. 



6. Remove Bearer Serv Accept 



Figure 7.3: Bearer Service Termination 

1 The TPF receives a request to remove a bearer service. For GPRS, this is the GGSN that receives a delete PDP 
context request. 

•« 

2 The TPF indicates that a bearer (for GPRS; a PDP. context) is being removed and provides relevant input 



information for the charging rule decision. 



Sp i 



3 The CRF determines the charging rules to be provisioned, based on information available to the CRF (e.g. 
information may be available from the AF as described in 7.1 and the new information received from the TPF). 
Charging rules may need to be added, and/or removed. 

4 The CRF provides the charging rule information to the TPF. This message is flagged as the response to the TPF 
request. 

i 

5 The TPF installs/removes the charging rules as indicated. 

6 The TPF continues with the bearer service removal procedure. 

Note: In the case of GPRS, the bearer service termination procedure may also be initiated by other nodes such 
as the SGSN. 



Editor's Note: It is FFS whether the bearer service tenriination procedure can proceed in parallel with the 
indication of bearer termination. 
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7.3 Provision of Charging Rules triggered by other event to the 

CRF 



UE 



TPF 



V I 
► 



CRF 



1 . Internal or exter lal trigger event 



2. Identify charging 
rules to apply 



3. Provision Charging Rules 



4. Install/Remove 
charging rules 



(if required) 



Figure 7.4: Provision of Charging Rules due to external or internal Trigger Event 

1 The CRF receives a trigger event, with relevant information related to the event. One example event is an AF 
interaction as described in 7.1. J ' • >' ; 

2 The CRF determines the charging rules to be added/removed, based on information available to the CRF (e.g. 
information may be available from the AF as described in 7.1 and the new information received from the 
trigger). Charging rules may need to be added, and/or removed. 

3 If required, the CRF provisions the charging rules to the TPF. 



4 The TPF installs/removes the charging rules as indicated. 



> ■ • 
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Annex A (informative): 

Overall architectural impacts of IP flow based charging 

A.1 GGSN in HPLMN 

One of the underlying drivers for the IP flow charging work is to permit greater flexibility in PS domain charging, and, 
to control this flexibility in the HPLMN. This is a fairly fundamental change from the concepts that lead to 
development of the CAMEL 3 standards (which provide the capability for pre-pay charging on the SGSN) and some 
aspects of the IMS architecture (e.g. P-CSCF and I-CSCF), 

This movement towards charging in the "GGSN arena" rather than "charging at the SGSN" leads to a few questions: 

a) is all the information that the SGSN places on the S-CDR available at the GGSN? If not, what is missing, is it 
important, and, can GTP be upgraded to provide it to the GGSN? 

* 

b) when this information is passed to the GGSN, can it then be made available as extra Radius parameters? 

c) does this information need to be sent on the Gx and/or Gy and/or Gz interfaces? 

A.2 Comparison of S-CDR and G-CDR fields 

i » i -i . > • • i ii 

i 

A.2.1 S-CDR information missing from G-CDR 

i . ■ • 

The following fields are present in the S-CDR but absent from the G-CDR 

- Served IMEI; 

- MS Network Capability; 

- LAC/RAC/CI at "record opening"; , . 

* i 

* • ■ . ; . 

- Access Point Name Operator Identifier; 

- System Type; 

- CAMEL information; . r.V-^o - 

- RNC unsent data volume. ' r " 1 
These parameters are analysed further in the' following subsections. 

A.2.2 Served IMEI 

■ 

This information is useful for many operational/statistical purposes within the HPLMN. Examples might include 
checking whether the SIM-IMEI combination "is correct"; which brands of mobile generate what proportion of revenue 
streams and/or access particular types of services; etc. 

Hence it is recommended to provide the IMEISV to the GGSN for transparent transfer within the GGSN to the G-CDR 
and/or Radius attribute. This means the addition of an optional parameter to the Create PDP Context Request message. 

Note that the IMEISV should be provided rather than just the IMEI because the SV information has some value, and, 
IMEISV is as equally easy for the SGSN to obtain as the IMEI. 
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A.2.3 MS Network Capability ' 

This is the "core network" part of the mobile's classmark. Review of 24.008 shows that most of the really interesting 
information for the HPLMN is contained within the Radio Classmark information and not within the MS Network 
Capability. However, the Radio Classmark information is not included on the S-CDR. 

Hence statistical information gathering (such as, what proportion of UK data traffic is carried by mobiles that support 
the PCS 1900 spectrum) has to be gathered from analysis of IMEIs rather than analysis of the Classmark field. 

Hence, provided IMEISV is sent to the GGSN, this field need not be sent to the GGSN. 

A.2.4 LAC/RAC/CI at "record opening" 

Various tariffs can be imagined that use cell ID information (e.g.a home cell 'tariff, whereby, if the context is opened in 
your home cell, a certain volume of data is charged at a lower rate). Statistical information gathering is also performed 
on a per cell basis. 

Hence knowledge of the "full" cell ID at the GGSN would be useful. 

Note that the "full" cell ID includes the MNC and MCC - but these fields have recently been added to R'97 and R'99 
GTP. During the debate on this topic, it might have been argued that the 3G-SGSN did not know the Service Area Code 
where the mobile was activating the PDP context. However, this seems to be incorrect, because study of RANAP shows 
that the RNC is required to add the mobile's current SAI to every Direct Transfer message sent to the SGSN, 

There may be some concerns about sending cell-ID information between networks, however, it may well already be 
sent in the inter-operator TAP records! Also, as a "ball park figure", 90% of subscribers are in their home network and 
10% are roaming abroad, and the main usage of this field would be for the 90% of subscribers in their HPLMN. 

So, it seems useful to add CGI/SAI information into the GTP signalling. 

i 

Further complexity arises however from theiphrase '•atVrecord ppening". In bqth SGSN and GGSN, it is possible to raise 
partial CDRs. A "partial CDR" is potentially generated every 15 minutes and reduces the fraud risks associated with 
only generating a full CDR after many mega bytes have been sent on a PDP context that has been open for several days. 
From reading 32.215 it seems that the Cell ID needs to be insertedinto the S-CDR every time a partial CDR is opened. 

Full support of the Cell ID in Partial G : CDRs appears difficult, however, a useful compromise would seem to be to add 
CGI/SAI information to all GTP messages that can be sent 'by the SGSN as a result of receiving a RANAP Direct 
Transfer message. When the mobile is using the Gb interface, the SGSN should add the CGI to these messages. 

♦ 

Hence it is recommended to add CGI/SAI as an optional parameters in the following GTP messages: 

■ « ► 

- Create PDP Context Request; 

- Update PDP Context Request. 

Whether or not the CGI/SAI is included by the SGSN should be controlled by the SGSN operator according to the 
PLMN-ID of the GGSN. 

» 

A.2.5 Access Point Name Operator Identifier 

Section 14.13 of 3GPP TS 23.060 states that this field is part of the APN and that the APN is used to identify the 
GGSN. As such, it is logical that this field is included on the S-CDR. 

i 

However, there appears to be absolutely no need to transfer this field to the GGSN. 

A.2.6 System Type 

On the S-CDR, this indicates whether the SGSN serves 2G or 3G cells. There is no code point for a combined 2G/3G 
SGSN, and no indication as to whether or not the combined SGSN has separate 2G and 3G Routeing Areas! 

t 

It is recommended to add an "SGSN type" information element to the following GTP messages: 
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- Create PDP Context Request; 

- Update PDP Context Request. 

The contents of the "SGSN type" information element should be able to encode the following information, and permit 
future backwards compatible extension: 

- 2G only SGSN; 

- 3G only SGSN; 

1 ! . . • • ■ 

1 » S 

■m ^ » i H m I * • I 

V 

- Combined 2G/3G SGSN with all 2G cells in separate Rputeing Areas to 3G cells; 

- Combined 2G/3G SGSN with some 2G and 3G cells in the same Routeing Area. 

Future additions might be needed to add in UMTS FDD/TDD differentiation, or if new Radio Access Technologies are 
adopted in the future. 

Note that this "SGSN type" is different to the current "System 1 type" field on the S-CDR. Whether or not the "System 
type" field on the S-CDR should be updated is FFS. 

A.2.7 CAMEL information 

Some CAMEL functionality relates to SGSN based on-line charging. When using SGSN based on-line charging, GGSN 
based on-line charging is unlikely to also be used. However, other CAMEL functionality relates to APN ID 
manipulation; SGSN resource utilisation, and the provision for the gsmSCF to write a "free format field" to the main 
CDR. This information appears to be useful to transfer to the GGSN. 

Overall it appears simplest to transfer all the S-CDR CAMEL Information as one parameter from the SGSN to the 
GGSN. The format and encoding of this information element should be constructed in an extensible manner, hopefully 
by just referencing the encoding already used within 3GPP TS 32.215. 

This information element should be included in the Create PDP Context Request and Update PDP Context Request 
messages. 

A.2.8 RNC unsent data volume 

If this information is useful to an SGSN, then it should be passed to the GGSN. In doing so it needs to be supplemented 
by the "2G SGSN unsent data volume". Probably the unsent data volume could.be accumulated by the new SGSN and 
sent to the GGSN at PDP context release. Providing this information to the new SGSN at inter SGSN change may 
require new GTP messages. Obtaining the information from the RNC may require additional use of existing RANAP 
signalling procedures. 

» 

However, as the value of sending this information from the RNC to the SGSN is as yet unclear, so far it is not agreed to 
add this information into the GTP signalling. 

A.3 RADIUS attributes 1 

With the provision of the above information to the GGSN, then if RADIUS accounting is applied in the operator's 
network then it is recommended that the following RADIUS attributes are added to the appropriate RADIUS messages: 

- IMEISV; ' ' 

I , r 

- CGI/SAI; 

- SGSN type; 

- CAMEL information. 
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Annex B (informative): 

IMS and Flow based charging 

Flow Based Charging offers other ways that IMS service may be charged. Considering this, we need to study the usage 
of Flow Based Charging in relation to IMS. 

i ■ 

The following needs to be studied: 

1 . Flow Based Charging needs to provide a solution.to the issues solved by Rel5 IMS correlation, considering 
issues such as backwards compatibility. 

2. It needs to be clarified whether having multiple filters provided to the GGSN (over Go and Gx) is an issue (and 
if it is, it needs to be resolved). 

3. How charging rules can be applied to the SIP signalling used for IMS session control 

« * 

B.1 IMS SIP signalling 

This section studies how flow based charging can be applied to the IMS signalling used for IMS session control 

It is to be noted though that the SIP signalling itself could carry different type of information that may be charged 
differently (e.g. SIP Session Invites, IMS messaging, etc.). ... 

Possible ways to charge SIP at the bearer l ( evel could consist of: 

- Applying pre-configured static rules in the TPF; 

■ 

- Requesting charging rules from the CRF; > . 

- Updating charging for the IMS signalling charging rules based specific triggers (e.g. time of day, modification of 
the session parameters, etc.) for a given user. 

Note: the usage of the signalling indicationjieeds tq<be further studied with respect to Flow Based Charging. 

■ ■ • • , ' • i 

» 

i 

B.2 Rx/Gx functions and SBLP usage 

■ 

Dynamic media stream filter information for QoS policy and charging correlation may be provided to the GGSN via the 
Gq and Go interfaces. This is described in TS 23.207 and TR 23.9 17. 

Dynamic and static media stream filter information for charging (data for the charging rules) may be provided to the 
Traffic Plane Function (GGSN in the case of GPRS) via the Rx and Gx interfaces. This is described in this TS. 

These, two functions are independent and thus can be provided separately. 
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Annex C (informative): 

WLAN and flow based charging 

i - 

C.1 TPF usage for WLAN 

For WLAN, the current working assumption is that the TPF is a logical function allocated to the PDG. It is FFS how 
this will be impacted by the ongoing WLAN/3GPP architecture work. 




■ * * 
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Foreword 

This Technical Report has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

Introduction 

This clause is optional. If it exists, if is always the second unnumbered clause. 
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1 Scope 

The present document identifies the overall architecture aspects of IP flow based bearer level charging. 
It is expected that the content of this TR will act as a basis for: 

- Change requests against the architecture specifications [5] of SA2, clarifying the architecture implications of IP 
flow based bearer charging 

- Change requests against the Charging Principles specification [3j of SA5, which contains the charging 
architecture and mechanisms. 

2 References 

The following documents contain provisions which, through reference in mis text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[1] 3GPP TR 41.001: "GSM Release specifications 0 . 

[2] 3GPP TS 21.905: "Vocabulary for 3 GPP Specifications". 

[3] 3GPP TS 32.200: "Charging Principles". 

[4] 3GPP TS 23.228: "IP Multimedia (IM) Subsystem - Stage 2 M . 

[5] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 



For the purposes of the present document, the terms and definitions given in TS 21.905 [2] and the following apply: 

Editor' 8 noic: terms shown in <anglc brackcis> are provisional. 

Packet flow: a specific user data flow carried through the Traffic Plane Function. 

Service data flow: aggregate set of packet flows. A packet flow can be an IP flow. 

In the case of GPRS, it shall be possible that a service data flow is more granular than a PDP context. 

Service Data Flow Filter: a set of filter parameters used to identify one or more of the packet flows constituting a 
service data flow. At least the following means for the packet flow identification shall be supported: source and 
destination IP address+port, transport protocol, or application protocol. 

Charging rule: data that identifies the service data flow filters, charging key, and the associated charging actions, for a 
single service data flow. 
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Charging key: information used by the online and offline charging system for rating purposes. The charging key is an 
identifier associated with the charging rule that is unique within the charging rules for that users IP address/prefix. 

Dynamic charging rules: Charging rules where some of the data within the charging rule (e.g. service data flow filter 
information) is assigned via real-lime analysis which may use dynamic application derived criteria. 

Static charging rules: Charging rules where all of the data within the charging rule describing the service data How is 
permanently configured throughout the duration of a user's data session. Static charging rules may be activated 
dynamically. 

Predefined charging rules: Static charging rules which are defined in the Traffic Plane Function. 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



<symbol> 



<Explanation> 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



AF 

BS 

CCF 

CDR 

CGF 

CRF 

CSCF 

ECF 

GCID 

GGSN 

GPRS 

HPLMN 

HTTP 

ICID 

IM 

IMCNSS 

IMS 

IMSI 

OCS 

P-CSCF 

PDGw 

PLMN 

PSTN 

QoS 

S-CSCF 

SGSN 

SIP 

TPF 

UE 

WAP 

WLAN 



Application Function 
Billing System 

Charging Collection Function 
Charging Data Records 
Charging Gateway Function 
Charging Rules Function 
Call Session Control Function 
Event Charging Function 
GPRS Charging ID 
Gateway GPRS Support Node 
General Packet Radio Service 
Home PLMN 



Hypertext Transfer Protocol 
IMS Charging Identifier 
IP Multimedia 

IP Multimedia Core Network Subsystem 

IP Multimedia Core Network Subsystem 

International Mobile Subscriber Identity 

Online Charging System 

Proxy-CSCF 

Packet Data Gateway 

Public Land Mobile Network 

Public Switched Telephone Network 

Quality of Service 

Serving-CSCF 

Serving GPRS Support Node 

Session Initiation Protocol 

Traffic Plane Function 

User Equipment 

Wireless Application Protocol 

Wireless LAN 
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4 General Charging Architecture Requirements 

Editor's note: This clause is planned to contain the relevant archiceciure requirements related lo IP flow level 
charging. 

4.1 General 

The current level of traffic differentiation and traffic-type awareness of the GPRS architecture shall be extended beyond 
APN and PDP Context level. It shall be possible to apply differentiated charging for the traffic flows belonging to 
different services (a.k.a. different service data flows) even if they use the same PDP Context. 

Charging and tariffing models described in this Technical Report shall be possible to be applied to both prepaid and 
postpaid subscribers, i.e. to both online and offline charging. 

The GPRS online charging solutions up to release 5 are built around CAMEL mechanisms that provide online access- 
and charging-control for GPRS - pertaining to PDP Contexts of an APN. 

The evolved bearer charging architecture developed in this Technical Report shall use generic native IP charging 
mechanisms to the extent possible in order to enable the reuse of the same charging solution and infrastructure for 
different type of IP-Connectivity Networks. 

Note: Providing differentiated service-data flow-based charging is a different function from providing 

differentiated traffic treatment on the IP-flow level. The operation of service-data flow-based charging 
shall not mandate the operation of service-based local policy. At the same time, the relationship of the 
PDP Context based service-based local policy mechanisms of the Go interface and the service data flow 
based charging mechanisms will have to be carefully studied. 

The following new release 6 functions need to be provided by the network for service data flow based charging: 

• Identification of the service data flows that need to be charged at different rates 

• Provision and control of service data flow level charging rules 

• Reporting of service data flow level packet counts for offline and online charging 

• Event indication according to on-line charging procedures (e.g. sending AAA Accounting Stop) and, optionally, 
following this particular event, taking appropriate actions on service data flow(s) according to the termination 
action defined in the respective charging rule(s). 

These new functions shall be compatible and coherent with the authentication, authorization, PDP context management 
roaming and other functions provided by the existing architecture. 

In addition charging based on specific application services or protocols shall be supported. 

4.2 Traffic Plane Function 

This refers to the filtering that identifies the service data flows that need to be charged at different rates Basic example- 
look for packets to and from service A. 

• Different filtering and counting shall be supported for downlink and uplink. 

• Different granularity for service data flow filters identifying the service data flow shall be possible e.g. 

• Filters based on the IP 5 tuple (source IP address, destination IP address, source port number, destination port 
number, protocol ID of the protocol above IP). Some of the filler parameters may be wildcarded. 

• Supporting filtering with respect to service data flow based on the transport and application protocols used 
above IP shall be possible for HTTP and WAP. This includes the ability to differentiate between TCP 
Wireless-TCP according to WAP 2.0, WDP, etc, in addition to differentiation at the application level. 
Filtering for further application protocols and services may also be supported. 
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In the case of GPRS, the traffic plane function shall provide the ability to support simultaneous independent 
filtering on service data flows associated with all, and each individual active PDP contexts; that is, primary and 
secondary PDP contexts, of one APN. 

In case of no applicable filters for a service data flow, an operator configurable default charging should be 
applied. 
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Figure 4.2 - Relationship of service data flow, packet flow and service data flow filter 



4.3 Charging rules 

Charging rules contain information that allow for filtering of traffic to identify the packets belonging to a particular 
service data flow, and allow for defining how the service data flow is to be charged. The following apply to charging 
rules: 

• Charging rules for bearer charging shall be defined by the operator. 

• These charging rules shall be made available to the Traffic Plane function for both offline and online charging. 

• Multiple charging rules shall be supported. 

• Filtering information within a charging rule is applied through filtering functionality at the Traffic Plane 
Function to identify the packets belonging to a particular service data flow. 

• Charging rules with statically provisioned filtering information (i.e. pre-defined at the Traffic Plane Function) 
shall be supported 

• Charging rules with dynamically provisioned filtering information (i.e. made available to the Traffic Plane 
Function) shall be supported in order to cover IP service scenarios where the filtering information is dynamically 
negotiated (e.g. negotiated on the application level (e.g. IMS)). 

• Pre-defined charging rules shall be supported. 

Editor's Note: Specifying the application of static rules (eg. sialic rules for all users, sialic rules per user) is FFS. 

• There may be overlap between the charging rules that are applicable. Overlap can occur between: 

• multiple pre-defined charging rules in the TPF 
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• charging rules pre-defined in the TPF and rules from the Service Data Flow Based Charging Rules 
Function, which can overlay the pre-defined rules in the TPF 

The precedence identified with each charging rule shall resolve all overlap between the charging rules. 

• Charging rules contain information on 

• How a particular service data flow is to be charged: online/offline 

• In case of offline charging whether to record volume- or time-based charging information 

• In case of online charging, what termination action is to be applied 

• Charging key 

• Service data flow fiUcr(s) 

• Precedence 

• Elements of charging rules may either be statically configured at the Traffic Plane Function, or may be 
dynamically provisioned. 

Note: The mechanism to support use of elements statically pre-defined in the TPF (e.g. filter information) is for 
stage 3 development. 

• Once the charging rule is determined it is applied to the service data flow at the Traffic Plane Function and 
packets are counted and categorised per the rule set in the charging rule. 

• Different charging rules shall be supported in downlink and uplink. 

• Charging rules shall be available for both user initiated and network initiated flows. 

• Charging rules can change and be overridden, for a previously established PDP context in the GPRS case, based 
on specific events (e.g. IM domain events or GPRS domain events). 

• It shall be possible to apply different charging rules for different users or groups of users. 

• It shall be possible to apply different charging rules based on the location of the user (e.g. based on identity of 
the roamed to network). 

• Overlap between charging rules (whether static or dynamic) applied for a user shall be identified, and resolved 
according to operator specified rules. 

• For GPRS, charging rule assignment shall be possible at PDP context establishment. 

• For GPRS, it shall be possible to have different charging rules depending on the APN used. 

4.3.1 Termination Action 

Termination Action applies in case of online credit control, each charging rule has a corresponding termination action 
defined for service data flows that are online charged. The termination action indicates the action which the Traffic 
Plane Function should perform when the on-line charging system causes the Diameter Credit Control Client to 
terminate a service data flow. 

This clause defined the termination action at the Traffic Plane Function. Termination Actions may also be defined in the 
OCS. 

The defined termination actions include: 

• Drop the packets corresponding to a terminated service data flow as they pass through the Traffic Plane 
Function. 

Additional termination actions such as re-dirccting packets corresponding to a terminated service data flow are to be 
investigated 
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No termination action means that the packets corresponding to a terminated service data flow will be allowed to pass 
through the Traffic Plane Function. The charging actions in this case are FFS. 

The Termination Action may trigger other procedures, e.g. the deactivation of a PDP context or the termination of a 
WLAN session. 



4.3.2 Credit management 

In case of online charging, it shall be possible to; 

1. have a pool of credit/resource used for multiple charging rules applied at the Traffic Plane Function. 

2. have individual credit/resource limits for each charging rule applied at the Traffic Plane Function 
Rating decisions shall be strictly controlled by the DCS for each service. 

Note: 'credit' as used here does not imply actual monetary credit, but an abstract measure of resources available to the 
user. The relationship between this abstract measure, actual money, and actual network resources or data transfer, is 
controlled by the OCS. 

4.4 Reporting 

This refers to the differentiated charging information being reported to the existing charging architecture. Basic 
example: those 20 packets were in rating category A, include this in your global charging information. 

• The Traffic Plane function shall report bearer charging information for online 

• The Traffic Plane function shall report bearer charging information for offline 

• It shall be possible to collect charging information based on the bearer charging rules (service data flow related 
charging information), and in the case of GPRS, release 5 charging rules (per PDP context) 

• It shall be possible to report charging information showing usage for each user for each charging rule, e.g. a 
report may contain multiple containers, each container associated with a charging key. 

4.5 Backwards compatibility 

The enhanced architecture shall be backwards compatible with release 5 charging capabilities. 

4.6 Charging models 

When developing the charging solutions, the following charging models should be considered, even though the full 
solution to support the models may not be within the scope of this TR. 

Shared revenue services shall be supported. In this case settlement for all parties shall be supported, including the third 
parties that may have been involved providing the services. 

Charging models where service data flow charging depends on the volume of data or the duration of the session shall be 
supported, as well as those where service data flow charging depends on the time of day. 

It shall be possible to restrict special rates to a specific service, e.g. allow the user to download a certain volume of data 
from one service for free, but this allowed volume is not transferable to other services. 

In the case of online charging, and where information is available to enable service data now packets to be associated 
with a specific PDP context, it shall be possible to perform rating and allocate credit depending on the characteristics of 
the resources allocated initially (in the GPRS case, the QoS of the PDP context). 

The flow based bearer level charging can support dynamic selection of charging to apply. A number of different inputs 
can be used in the decision to identify the specific charging to apply. For example, a service data flow may be charged - 
with different rates depending on what QoS is applicable. The charging rate may thus be modified when a bearer is 
created or removed, to change the QoS provided for a flow. 
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The charging rate or charging model applicable lo a flow may also be changed as a result of a events in the service (eg 
insertion of a paid advertisement within a user requested media stream). 



5 



Architectural Concept 



5.1 



Architecture and Reference Points 



Editor's note: This clause is planned to contain the relevant pai l of the architecture impacted by IP flow level based 
cisanrhm. 



5.1 .1 Online service data flow-based bearer charging architecture 

Figure 5.1 below presents the overall architecture for service data flow-based online bearer charging. 
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Service Data 
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Figure 5.1 - Overall architecture for service data flow based online bearer charging 

Note: No changes are foreseen on the CAMEL SCP. The relation of the new entities and interfaces described in this 
figure to existing entities and interfaces of the 3 GPP system architecture (e.g. SGSN, GGSN) arc FFS. 

Noic(*): The detailed functional entities of the Online Charging System are not shown in this figure. The details of 
the OCS are specified in TS 32.200, further internal details of the OCS for release 6 are expected to be 
specified by SA5. 

The CAMEL-SCP depicted on the figure above performs the functions of the ReI-5 Bearer Charging 
Function defined in TS32. 200. 



5.1 .2 Offline service data flow-based bearer charging architecture 

Figure 5.2 below presents the overall architecture for service data flow-based offline bearer charging. 
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Figure 5.2 - Overall architecture for service data flow based offline bearer charging 

Note: No changes are foreseen on the CCF; The relation of the new entities and interfaces described in 
this figure to existing entities and interfaces of the 3GPP system architecture (e.g. SGSN, GGSN) are 
FFS. 

5.2 Functional Entities 

Editor's note: This clause is planned to contain the description of new and modified functional entities. 

5.2.1 Service Data Flow Based Charging Rules Function 

This entity provides service data flow level charging rules. This same functionality is required for both offline and 
online charging. The charging rules function accesses information stored in the service data flow based charging rules 
data repository. An external interface to the charging rules data repository may be used for management of the charging 
rules within the data repository. Specification of interfaces to the data repository is out of scope of this TR. 

The service data flow based charging rules function supports both static and dynamic charging rules. 

The service data flow based charging rules function determines what charging rules including precedence to apply for a 
user. 

The service data flow based charging rules function will receive information from the application function that allows 
the service data flow to be identified, and this information may be used within the charging rule (i.e. protocol, ip 
addresses and port numbers). Other information that is received by the service data flow based charging rules function 
(i.e. application identifier, type of stream) may be used in order to select the charging rule to be applied. 

5.2.2 Service Data Flow Based Credit Control Function 

The Service Data Flow- Based Credit Control Function performs online credit control functions together with the Online 
Charging System. It provides a new function within the release 5 Online Charging System. 

The Online Charging System is specified in 3GPP TS 32.200. The Service Data Flow Credit Control Function is 
considered as a new functional entity for release 6 within the Online Charging System. 

5.2.3 Charging Collection Function 

The Charging Collection Function is specified in 3GPP TS 32.200. 
The service data flow based charging requires no changes in the CCF. 
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5.2.4 Traffic Plane Function 

The Traffic Plane Function shall support pre-defined charging rules. 

The Traffic Plane Function shall be capable of differentiating user data traffic belonging to different service data flows 
for the purpose of collecting offline charging data and performing online credit control. 

See section 4.2 for requirements of the Traffic Plane Function. 

For online charging, the Traffic Plane Function shall be capable of managing the aggregation of the credit/resource used 
for some or all of the service data flows of a user. The Traffic Plane Function shall aJso be capable of managing the 
credit/resource of each individual service data flow of the user. 

For GPRS, it shall be possible to provide these functions for different service data flows even if they are carried in the 
same PDP Context. For GPRS, the traffic Plane Function is a logical function allocated to the GGSN. 

Editor's Note; The effects of this co-location to the interfaces still needs to be studied eg. Gy, Gz, Gi. Gi radius 
extensions for charging purposes arc not precluded. 

The Traffic Plane Function shall evaluate received packets against the service data flow filters in the order according to 
the precedence for the charging rules. When a packet is matched against a SDF filter, the packet matching process for 
that packet is complete, and the charging rule for that SDF filter shall be applied. 

Editor's Note: The relationship of She Traffic Plane Function and WLAN inicrworianc nodes (e.g. WLAN PDGwi is 
«r\S. 

5.2.5 Application Function 

The application function provides information to the service data flow based charging rules function, which can then be 
used for selecting the appropriate charging rule, and also used for configuring some of the parameters for the charging 
rule. The operator configures the charging rules in the service data flow based charging rules function, and decides what 
data from the application function shall be used in the charging rule selection algorithm. 

The Application Function shall provide information to allow the service data flow to be identified. The Application 
Function shall also provide some other information that may be used in the charging rule selection process. 

The information provided by the application function is as follows: 

• Information to identify the service data flow. This shall include the following fields: 

- Protocol 

- Source and destination IP address 

- Source and destination port number 

The application function may use wildcards to identify an aggregate set of IP flows. 

• Information to support charging rule selection: 

- Application identifier 

- Application event identifier 

- Type of Stream (e.g. audio, video) (optional) 

- Data rate of stream (optional) 

Editor's Note: Additional information isFFS. 

The "Application Identifier" is an identifier associated with each service that an AF provides for an operator (e.g. a PSS 
application function would have one application identifier for the PSS service). 

The "Application event identifier" is an identifier within an Application identifier. It is used to notify the Service Data 
Row Based Charging Rules Function of such a change within a service session that affects the charging rules, e.g. 
triggers the generation of a new charging rule. 

5.3 Reference points 

Editor's note: This clause is planned to contain the description of new and modified reference points. 
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5.3.1 



New Reference points 



5.3.1.1 



Gx reference point 



The Gx reference point enables the use of service data flow based charging rules such as counting number of packets 
belonging to a rale category in the IP-Connectivity Network. This functionality is required for both offline and online 
charging. 

The Gx reference point supports the following functions: 

1. Initialisation and maintenance of connection 

2. Request for Charging Rules (from TPF to CRF) 

3. Provision of Charging Rules (from CRJF to TPF) 

4. Termination of PDP context (from TPF to CRF) 

5. Removal of Charging Rules (from CRF to TPF) 



Initialisation and Maintenance of Connection 

A single connection shall be established between a CRF and TPF pair. The connection can be direct, or established via a 
relay/proxy node. A connection may be redirected to an alternate node. 

The relevant intcrworking peer nodes may be configured, or may be determined through a discovery mechanism. At a 
failover, commands which have not been successfully received shall be queued to the alternate peer. 

The detail specification of the connection establishment and maintenance are for specification in stage 3. 

Request for Charging Rules (from TPF to CRF) 

At a bearer establishment/modification (PDP context establishment/modification for GPRS), the TPF requests the 
charging rules to be applied. 

The request must identify whether it is an initial request (primary context establishment for GPRS), or a subsequent 
request (i.e. for GPRS, a secondary PDP context establishment, or a PDP context modification). For an initial request 
for GPRS, the request must include IMSI, APN, and PDP address information. 

An identifier is required to allow the specific instance in the TPF/CRF to be identified for subsequent data exchange. 
The identifier for the communication must be provided. 

The request must provide further information used for the charging rule selection. The request must have an identifier 
for the bearer, the QoS information, and flow identifier information allocated to the bearer. For GPRS, this information 
would include the traffic class, and the TFT. 

Where the charging rule selection data for a bearer is modified, the TPF sends the request to the CRF indicating it is for 
a bearer modification, and providing the modified data. 



The CRF sends the charging rule information to be applied in the TPF. This may be a response to a Request for 
Charging Rules, or it may be unsolicited. 

The charging rule provision includes information about the instance it relates to (i.e. identifier for the relevant CRF/TPF 
instance), charging mechanism (online/offline), volume- or time-based charging indication, termination action, charging 
key, service data flow filters) v and precedence. 



The service data flow filters are specified separately for the uplink and downlink direction. 

Note: A charging rule may provide information for service data flows for one direction, or for both directions. 



Provision of Charging Rules (from CRF to TPF) 
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Termination of Bearer (from TPF to CRF) 

The TPF indicates to the CRF that a bearer is terminated. 

The bearer termination includes information to identify the instance it relates to (i.e. an identifier for the relevant 
CRF/TPF instance), and an indication of the bearer being removed (the PDP context in the case of GPRS). The 
termination also indicates if this is the last bearer for that TPF/CRF instance. 

Removal of Charging Rules (from CRF to TPF) 

The CRF sends an order to the TPF to remove one or more charging rules. 

The charging rule removal identifies the user it relates to (i.e. an identifier for the relevant CRF/TPF instance), and 
further identifies the specific charging rules to be removed. 

Editor's noic(ii): The functional relationship of the Gx function and further existing interfaces (e.g. the RADIUS- 
interface of the C3GSN defined in TS 29.061 ) has to be studied and specified. 

5.3. 1.2 Gy reference point 

The Gy reference point allows credit control for service data flow based online charging. The functionalities required 
across the Gy reference point use functionalities and mechanisms specified for the release 5 Ro interface. 

5.3.1 .3 Gz reference point 

The Gz interface enables transport of service data flow based offline charging information. 
For GPRS the relationship of the Gz interface and the existing Ga interface is FFS. 

5.3.1 .4 Rx reference point 

The Rx reference point enables transport of information (e.g. dynamic media stream information) from the application 
function to the charging rules function. An example of such information would be filter information to identify the 
packet flow. 

5.3.2 Existing reference points 

The functionalities across the reference points described in this clause are not intended to be modified within the 
context of the concepts specified in this TR. 

The Ro and Rf interfaces are specified for release 5 in TS 32.200 and TS 32.225. 
The Ge interface is specified by TS 23.078 and TS 29.078. 

5.3.3 Rx/Gx functions and SBLP usage 

Dynamic media stream filter information for QoS policy and charging correlation may be provided to the GGSN via the 
Gq and Go interfaces. This is described in TS 23.207 and TR 23.917. 

Dynamic and static media stream filter information for charging (data for the charging rules) may be provided to the 
Traffic Plane Function via the Rx and Gx interfaces. This is described in this TR. 

These two functions are independent and thus can be provided separately. 

6 Message Flows 

Editor's note: This clause is planned to contain the description of new and modified information flows. 
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Annex A: Overall architectural impacts of IP flow based 

charging 

A.1 GGSN in HPLMN 

One of ihc underlying drivers for the IP flow charging work is to permit greater flexibility in PS domain charging, and, 
to control this flexibility in the HPLMN. This is a fairly fundamental change from the concepts that lead to 
development of the CAMEL 3 standards (which provide the capability for pre-pay charging on the SGSN) and some 
aspects of the IMS architecture (eg P-CSCF and I-CSCF). 

This movement towards charging in the "GGSN arena" rather than "charging at the SGSN" leads to a few questions: 

a) is all the information that the SGSN places on the S-CDR available at the GGSN? If not, what is missing, is it 
important, and, can GTP be upgraded to provide it to the GGSN? 

b) when this information is passed to the GGSN, can it then be made available as extra Radius parameters? 

c) docs this information need to be sent on the Gx and/or Gy and/or Gz interfaces? 

A.2 Comparison of S-CDR and G-CDR fields 

A.2.1 S-CDR information missing from G-CDR 

The following fields are present in the S-CDR but absent from the G-CDR 

• Served IMEI 

• MS Network Capability 

• LAC/RAC/CI at "record opening" 

• Access Point Name Operator Identifier 

• System Type 

• CAMEL information 

• RNC unsent data volume 

These parameters are analysed further in the following subsections. 

A.2.2 Served IMEI 

This information is useful for many operational/statistical purposes within the HPLMN. Examples might include 
checking whether the SIM-IMEI combination "is correct"; which brands of mobile generate what proportion of revenue 
streams and/or access particular types of services; etc. 

Hence it is recommended to provide the IMEISV to the GGSN for transparent transfer within the GGSN to the G-CDR 
and/or Radius attribute. This means the addition of an optional parameter to the Create PDP Context Request message. 

Note that the IMEISV should be provided rather than just the IMEI because the SV information has some value, and, 
IMEISV is as equally easy for the SGSN to obtain as the IMEI. 

A.2.3 MS Network Capability 

This is the "core network** part of the mobile's classmark. Review of 24.008 shows that most of the really interesting 
information for the HPLMN is contained within the Radio Classmark information and not within the MS Network 
Capability. However, the Radio Classmark information is not included on the S-CDR. 
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Hence statistical information gathering (such as, what proportion of UK data traffic is carried by mobiles that support 
the PCS 1900 spectrum) has to be gathered from analysis of IMEIs rather than analysis of the Classmark field. 

Hence, provided IMEISV is sent to the GGSN, this field need not be sent to the GGSN. 

A.2.4 LAC/RAC/CI at "record opening" 

Various tariffs can be imagined that use cell ID information (eg a home cell tariff, whereby, if the context is opened in 
your home cell, a certain volume of data is charged at a lower rate). Statistical information gathering is also performed 
on a per cell basis. 

Hence knowledge of the "full" cell ID at the GGSN would be useful. 

Note that the "full" cell ID includes the MNC and MCC - but these fields have recently been added to R'97 and R'99 
GTP. During the debate on this topic, it might have been argued that the 3G-SGSN did not know the Service Area Code 
where the mobile was activating the PDP context. However, this seems to be incorrect, because study of RANAP shows 
that the RNC is required to add the mobile's current SAI to every Direct Transfer message sent to the SGSN, 

There may be some concerns about sending cell-ID information between networks, however, it may well already be 
sent in the inter-operator TAP records! Also, as a "ball park figure", 90% of subscribers are in their home network and 
10% are roaming abroad, and the main usage of this field would be for the 90% of subscribers in their HPLMN. 

So, it seems useful to add CGI/S AI information into the GTP signalling. 

Further complexity arises however from the phrase "at record opening". In both SGSN and GGSN, it is possible to raise 
partial CDRs. A "partial CDR" is potentially generated every 15 minutes and reduces the fraud risks associated with 
only generating a full CDR after many mega bytes have been sent on a PDP context that has been open for several days. 
From reading 32.215 it seems that the Cell ID needs to be inserted into the S-CDR every time a partial CDR is opened. 

Full support of the Cell ID in Partial G-CDRs appears difficult, however, a useful compromise would seem to be to add 
CGI/S AI information to all GTP messages that can be sent by the SGSN as a result of receiving a RANAP Direct 
Transfer message. When the mobile is using the Gb interface, the SGSN should add the CGI to these messages. 

Hence it is recommended to add CGI/S AI as an optional parameters in the following GTP messages: 

• Create PDP Context Request 

• Update PDP Context Request 

Whether or not the CGI/S AI is included by the SGSN should be controlled by the SGSN operator according to the 
PLMN-ID of the GGSN. 

A.2.5 Access Point Name Operator Identifier 

Section 14. 1 3 of 3GPP TS 23.060 states that this field is part of the APN and that the APN is used to identify the 
GGSN. As such, it is logical that this field is included on the S-CDR. 

However, there appears to be absolutely no need to transfer this field to the GGSN. 

A.2.6 System Type 

On the S-CDR, this indicates whether the SGSN serves 2G or 3G cells. There is no code point for a combined 2G/3G 
SGSN, and no indication as to whether or not the combined SGSN has separate 2G and 3G Routeing Areas! 

It is recommended to add an "SGSN type" information clement to the following GTP messages: 

• Create PDP Context Request 

• Update PDP Context Request 

The contents of the "SGSN type" information element should be able to encode the following information, and permit 
future backwards compatible extension: 

• 2G only SGSN 
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• 3G only SGSN 

• Combined 2G/3G SGSN with all 2G cells in separate Rouleing Areas to 3G cells 

• Combined 2G/3G SGSN with some 2G and 3G cells in the same Routeing Area 

Future additions might be needed to add in UMTS FDD/TDD differentiation, or if new Radio Access Technologies are 
adopted in the future. 

Note that this "SGSN type" is different to the current "System type" field on the S-CDR. Whether or not the "System 
type" field on the S-CDR should be updated is FFS. 

A.2.7 CAMEL information 

This needs some further study. 

A.2.8 RNC unsent data volume 

If this information is useful to an SGSN, then it should be passed to the GGSN. In doing so it needs to be supplemented 
by the "2G SGSN unsent data volume". Probably the unsent data volume could be accumulated by the SGSN and sent 
to the GGSN at PDP context release/inter SGSN change. 

However, as the value of sending this information from die RNC to the SGSN is as yet unclear, it is not yet proposed to 
add this information into the GTP signalling. 

A.3 RADIUS attributes 

With the provision of the above information to the GGSN, it is recommended that the following RADIUS attributes are 
added to the appropriate RADIUS messages: 

• IMEISV 

• CGI/SAI 

• SGSN type 
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